Manage DNS Integration with Active Directory
One of the great things you can do with DNS is integrate it with Active Directory. As you might recall from earlier in the tutorial, DNS is a requirement for installing AD. Active Directory has the ability to integrate DNS zone database information into the NTDS.DIT Active Directory database. This can have significant benefits for the security and replication of DNS data. In a typical Active Directory forest, there is more than one DC. When the AD database is replicated, the DNS database is replicated right along with it. This adds a degree of fault tolerance to the DNS data. Even if a server fails, you still have other DCs running DNS that can pick up the workload.
When you install AD using the dcpromo.exe tool, you are prompted to install DNS on the DC. This is the most common way of building DNS integration within AD. It is also possible to build something called Active Directory integrated zones that are not actually part of your AD namespace.
Integrate DNS with AD Domain Services
When you install Active Directory from Server Manager by adding the Active Directory role service, you will need to run dcpromo.exe to complete the installation of Active Directory. You will be given the option to install and configure a DNS server. If you choose to do this, the resulting server will be integrated with AD Domain Services. The nice thing about having your DNS integrated with AD is that when it comes to replication, the DNS zone information is going to be replicated along with the AD database. If you add DNS to the several DCs in your network, you get a built-in secure replication topology for DNS and a built-in fault tolerance strategy.
Build a DNS Application Directory Partition
The Active Directory database consists of partitions. Data from DNS zones can be stored in the domain partition or a partition called the application directory partition. If you store DNS zone data in the domain partition, it will inherit the replication parameters of the partition, which in short means you don't really control how the DNS data is replicated. Whatever the replication rules are for the domain partition become the rules for the DNS zone. That is not necessarily a bad thing. What if you wanted to control the replication parameters independent of the domain partition? You would build an application directory partition for DNS. By building an application directory partition, you have differentiated the DNS zone data from the AD domain data. In short, this gives you the opportunity to control the replication of the application directory partition without influencing or affecting the domain partition.
To create your own application directory partition for DNS, you will need two things. First, you will need membership in the Enterprise Admins security group, and second, you will need to know enough about dnscmd to enter a one-line command:
dnscmd (yourservername) /CreateDirectoryPartition (FQDN)
Your server name can be specified by name or by IP address. If you are working from the local DNS server, you could simply use a period to indicate the local server. When you use this command, it is important to know that the FQDN will specify the name of the new application directory partition. You must use an FQDN, such as dnspartition.xyz.com.
With a DNS application directory partition, you have a great tool for managing replication and fault tolerance. When you create the partition, there is only a single DNS server that is part of the partition. If you want to have additional servers participate as part of the partition, you need to add them to the partition. The technical term for this process is called enlisting a DNS server in an application directory partition. Much like creating the partition, enlisting servers requires that you use the dnscmd tool with the following syntax:
dnscmd (servername) /EnlistDirectoryPartition (FQDN)
The parameter requirements are similar to those you used in creating the application directory partition, where (servername) is the server name you are enlisting and (FQDN) is the fully qualified domain name of the application directory partition you created earlier, dnspartition.xyz.com.
There is one last concept associated with application directory partitions that you need to be aware of before moving to another topic. It is essential that once you create your application directory partition and enlist your DNS servers in the partition that you verify the application directory partition and its enlisted members. Again, you will use the command line:
dnscmd /EnumDirectoryPartitions
This command will execute and display all the directory partitions in which this server is enlisted.
The following command will display the information related to the specified directory partition. This way, you can verify your application directory partition and the enlisted members of the partition.
dnscmd (servername) /DirectoryPartitionInfo (FQDN)
Remove a DNS Server from an Application Directory Partition
As your network evolves and you add, modify, and remove servers, the situation may arise when you need to remove a server from your application directory partition. Remember that once a DNS server is removed from the partition, it will no longer participate in DNS replication. In other words, make sure you want the server out of the loop before you remove it from your application directory partition. Just like you used the dnscmd tool to create application directory partitions and enlist servers, you will also use dnscmd to remove a DNS server from an application directory partition. You will need DNS Admins or Domain Admins permissions to complete this configuration change.
dnscmd (servername) /UnenlistDirectoryPartition (FQDN)
Here again, (servername) is the name of the DNS server you want to remove, and (FQDN) is the fully qualified domain name of the application directory partition.
Finally, although you are free to enlist or unenlist DNS servers from application directory partitions that you have built, you cannot unenlist DNS servers from the DomainDnsZones or ForestDnsZones application directory partitions.
Change Security for a Directory Integrated Zone
It is possible to change the security of a directory integrated zone in DNS. Each object in Active Directory has something called a discretionary access control list (DACL), which defines the users and groups that have access to the object. You can set the permissions of the DACL to allow specific users or groups access to update your DNS zone database files.
- Open DNS Manager.
- Find the zone you are interested in maintaining.
- Right-click, and choose Properties.
- Click the Security tab.
- Edit the permissions as needed.
Remember that this procedure works only for Active Directory integrated zones. If you have a standard primary, standard secondary, or other zone type, this procedure is not available.
In this tutorial:
- Administering DNS
- Add and Remove DNS Servers
- Configure a New DNS Server
- Add Query Forwarding
- Configure a Caching-Only DNS Server
- Remove a DNS Server
- Manage a DNS Server
- Scavenge Properties for DNS
- Manage DNS Integration with Active Directory
- Change Zone Replication
- Manage Zone Database Files
- Configure Single-Label DNS Resolution
- Troubleshoot DNS