Manage Learn to apply best practices and optimize your operations.

DNS Primer: Tips for understanding Active Directory integrated zone design and configuration

Microsoft's development of the Active Directory integrated (ADI) primary DNS zone has some useful benefits for administrators. Gary Olsen's article defines ADI and tells you how to maximize its benefits.

Microsoft's development of the Active Directory integrated (ADI) primary DNS zone has some incredible benefits...

such as built-in recovery, scalability and performance. Here are my thoughts on it that will provide some details on what ADI primary zone really means, how to configure it and how to implement it in your environment. Next month we'll examine some problems with ADI and how to solve them.

In an ADI primary zone, rather than keeping the old zone file on a disk, the DNS records are stored in the AD, and Active Directory replication is used rather than the old problematic zone transfer. If all DNS servers were to die or become inaccessible, you could simply install DNS on any domain controller (DC) in the domain. The records would be automatically populated and your DNS server would be up without the messy import/export tasks of standard DNS zone files.

What constitutes an ADI zone?

An ADI zone is a writeable copy of a forward lookup zone that is hosted on a domain controller. This is a requirement since the DNS records are all held in the AD, thus the DNS server needs access to the AD. Since each DC hosts a writeable copy of the DNS zone, clients (workstations, servers and other DCs) can register their DNS records on a domain controller hosting an ADI primary zone -- usually the DC that authenticated them -- rather than search the network to find a single DNS server (primary) that will add the client's host and resource records.

All of the DNS records are held in the Active Directory in CN=MicrosoftDNS, CN=System,DC=corp,dc=net, as shown in Figure 1.

Figure 1

How do I create an ADI zone?

The option to create the ADI zone in Windows 2000 is exposed in the zone properties dialog as shown in Figure 2, while Figure 3 shows the options in Windows Server 2003. Note that in Windows 2000 there was simply the option to create an Active Directory integrated zone. In Windows Server 2003, in addition to the option to "store" the zone in Active Directory, you have several options (shown in Figure 4) to specify how you want the zone data to be replicated, including:

  • To all DNS servers in the forest
  • To all DNS servers in the domain
  • To all domain controllers in the domain
  • To all domain controllers in a particular Application Directory partition.


Figure 2


Figure 3


Figure 4

Selection of the second option, to replicate DNS information only to DNS servers in the domain, provides a way to limit DNS replication to only DNS servers, whereas it was replicated to all DCs in Windows 2000 -- whether they were DNS servers or not. This can have a significant impact on large organizations.

How do I design a DNS structure using ADI zones?

As I noted previously, ADI zones can only be hosted on DCs. However, many administrators want to put domain name servers in remote sites to provide better name-resolution performance and to decrease network traffic. That way, users don't have to go across the WAN to find a DNS server. However, you may not want to put a DC in that location. Windows 2000 and 2003 allow you to put a standard secondary zone (read only) on a member server and use one of the ADI primary servers as the master.

Figure 5 shows a conventional standard primary and secondary configuration, with a single, writeable primary server with several secondaries. Figure 6 shows how you can implement standard secondary servers in an ADI primary zone. Here, you have a mixture of ADI primary DNS servers as well as member servers hosting standard secondary zones. Again -- the rule is that an ADI primary zone can only exist on a DC, but you can have a standard secondary of that zone on a member server. Thus, clients can connect to their local DNS server whether it is hosting the ADI primary or the secondary. When a client (DC, member server or workstation) tries to register, however, it can only register on a DNS server hosting the ADI primary zone. If the client points to a server hosting a secondary, the client will simply receive a referral to one of the primaries to be registered.

Note: Since the standard secondary servers have no way of using the zone data in Active Directory, they are still required to use standard zone transfers to stay in sync with the master (primary).

Figure 5

Figure 6

What is an "island of replication" and how does that affect my design?

The "island of replication" issue is an oldie but a goodie. It is described very well in Microsoft KB article 275278. At the beginning of the Windows 2000 days, Microsoft advised us to have each DNS server point to itself as the "Preferred DNS server" in TCP/IP properties and then to other DNS servers as "Additional DNS Servers." This caused a couple of problems.

  • Because each DNS server registered clients that pointed to it for DNS (in TCP/IP properties), each one had a different set of records that had to be replicated to the other DNS servers (normal AD replication). However, occasionally, CName records that were required for replication would not get replicated to all DNS servers, causing replication errors.
  • The island of replication also causes performance problems. Although I have never seen this documented by Microsoft, I have worked with many customers who have experienced poor performance when configured with each DNS server pointing to itself for DNS.
  • The DNS service may not start before name resolution for authentication is needed. This can be the case in large enterprises with a large DNS database. In one case, in Windows 2000, it took the DNS service more than 30 minutes to start on a reboot. Windows 2003 is much faster, which minimizes this issue.

Two performance solutions

To fix the replication island and performance problems, simply pick one DC/DNS server hosting the ADI primary zone (we'll call it the "Source") and configure it to point to itself. All other DC/DNS servers in the zone should point to that "Source" DC. Thus, only one DC/DNS server will point to itself for DNS. This won't affect clients or DCs that are not DNS servers. It forces all registration to go to a single DNS server where it is registered and then replicated to the other servers.

Microsoft describes this fix in KB 275278, which also states that the problem is fixed in Windows Server 2003, thus making this change unnecessary. However, I still recommend configuring ADI DNS so that only one DNS server points to itself for DNS and the others point to it for performance reasons. Anytime I talk to customers who have DNS configured so that each DNS server points to itself for DNS, I recommend (in some cases I demand) that they change it. One administrator, who argued with me about it but finally gave in, called me a few days later to tell me his DNS performance had improved dramatically.

As for the issue of the DNS service taking a long time to start, you can resolve that by simply configuring the DNS servers to "cross-point" to each other. I usually recommend that for environments with only two DNS servers. In reality, since it only occurs when you reboot the DNS server -- and hopefully those instances rarely occur -- it should not be a big issue.

ADI primary zones are amazingly redundant because even if all domain name servers bite the dust, as long as you have a domain controller that is alive, you can quickly get a DNS server online. Simply install the DNS service on any DC, and the zone will be automatically populated. However, the ADI configuration requires good design and you must understand it to make it work properly.

Next month I will describe a couple of interesting issues you'll face when ADI zones go bad!

Dig Deeper on Windows systems and network management