Windows Server 2008 R2 : Manage a DNS Server (part 2) - Manage DNS Integration with Active Directory & Change Zone Replication

4. Manage DNS Integration with Active Directory

One of the great things you can do with DNS is integrate it with Active Directory. 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.

4.1. 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, as shown in Figure 4. 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.

4.2. 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.

Figure 4. Installing AD with DNS

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)

4.3. 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.

4.4. Change Security for a Directory Integrated Zone

As you saw in Figure 11.8, 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.

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.

Figure 5. Changing DACL permissions for a DNS zone

5. Change Zone Replication

Controlling zone replication allows you to be able to decide the parameters for replication for the DNS zone. These parameters are often called the replication scope. When DNS is integrated with Active Directory, it is replicated along with the other AD partitions between domain controllers. Active Directory consists of forest and domain structures, and there are domain controllers at both logical levels of this hierarchy. This structure lends itself to four replication scope options:

• All DNS servers in the Active Directory forest: This scope option will replicate DNS zone data to all DNS servers in the Active Directory forest. That's a broad scope, and depending on the size and physical layout of your forest, it could have some significant impact on replication.

• All DNS servers in the Active Directory domain: This scope option will replicate DNS zone data to all DNS servers that are running on domain controllers in the Active Directory domain. This seems like a tighter scope than the forest scope, but if you think about the size limitations on a domain (functionally there really aren't any), this could present the same issues as the forest scope, albeit with the limitations of the domain.

• All domain controllers in the Active Directory domain: In this scope, you would replicate DNS zone data to all domain controllers whether they were DNS servers or not.

• All domain controllers in a specified application directory partition: This scope allows you to replicate DNS zone data to the domain controllers that you have enlisted in the application directory partition.

Each of the scope options can be used effectively depending on the network environment and DNS implementation in which they are implemented. If you had taken the time to create an application directory partition, it would make sense to change the replication scope to all domain controllers in a specified application directory partition. To make changes in replication scope, you will use the DNS Manager:

Figure 6. Configuring replication scope