The health of Active Directory for the most part depends on a good, efficient DNS structure.
While the DNS structure in a single domain is fairly simple, things can get complicated in a multiple domain forest. One of those complications involves the location of Global Catalog (GC) resource records and CName records.
This is how the process breaks down. When a client operation, such as authentication, needs to find a Global Catalog server, a DNS server is then queried and a specific global catalog resource record is found and returned to the client. The client subsequently contacts the GC. Other operations also query the GC (such as Exchange Server, cross domain searches, etc.) so locating the GC resource records is definitely an important function. Global Catalog records are located in the GC container under the _MSDCS subzone.
CName or "Alias" records are used specifically for replication. Domain controllers must communicate for replication by using each other's server globally unique identifier (GUID). In order to do that, a CName record that maps the server GUID to the fully qualified domain name (FQDN) of the DC is created in the root of the _MSDCS subzone. Figure 1 shows the CName records, identified by the server GUID in the name, and the GC container.
Figure 1
The CName records and GC records are in the _MSDCS zone. So what? Well, in a forest with two or more domains, the _MSDCS zone is different. The first domain created in the forest, of course, has the _MSDCS zone, which, as noted previously, contains the CName records and the GC records. All subsequent domains, however, will not contain CName or GC records (although they will each contain a _MSDCS zone). Thus, those records are only stored in the _MSDCS zone in the first domain in the forest, or the forest root domain.
This situation is illustrated in Figure 2. In this example, Corp.net is the parent domain and obviously the forest root. The contents of the _MSCDS zone for Corp.net are shown, including the GC container and the CName records. However, the NA.Corp.net and EU.Corp.net child domains do not contain GC or CName records.
Figure 2
So, what does this mean?
In this example, when a client in the NA domain needs to contact a GC, it will go to its local DNS server for the NA domain. That provides a referral to the Corp.net DNS server, which finds the GC record and then returns it to the client.
Obviously, this is not very efficient, especially if there is a slow or unreliable network and the Corp.net DNS server is in a different site from the client. If that "client" happens to be an Exchange server, it is a big deal. Even though you may have a GC server in the same site as the Exchange server, if the DNS records are on a server in another site, it still has to go to that site to get the record to find the local GC.
There can also be problems with replication. If two DCs in the EU domain replicate, they have to go through this same process to locate the CName record from the Corp.net domain DNS server. Again, with network issues and the referral process itself, that can cause intermittent disruption of replication.
There are at least two good solutions, but remember that the goal is to put the GC and CName records local to the clients or DCs that need them. The solutions are:
To create a secondary zone of the root domain's _MSDCS zone on each of the EU and NA domain's DNS servers.
To delegate the _MSDCS zone at the root domain to the two child domains. Of course the root domain will also contain a delegation.
I'm not a big fan of secondary zones. They are not held in Active Directory in an AD integrated zone. You have to rely on the messy zone transfers and they have to stay in sync.
The delegation solution is much cleaner in my opinion, and it's easier to manage and troubleshoot. Note that if you create a new Windows 2003 domain, and let DCPromo configure DNS, it will automatically delegate the _MSDCS domain. Of course when you add additional domains, you must add delegation records to those DNS servers as well. Figure 3 shows how the _MSDCS zone delegation looks in the DNS management snap-in.
Figure 3
If you have name resolution trouble with records in the _MSDCS zone or if it becomes corrupt, you can simply delete the zone and delegation record. Then you can either force re-registration by restarting the NetLogon service on the DCs or just wait for normal refresh.
The _MSDCS zone will be rebuilt using dynamic registration, and you can then delegate it again. Other than that, you troubleshoot this delegated zone as you would any other. Also note that if you have multiple domain trees in a single forest, such as Corp.net and Company.com, this still applies. In other words, if Corp.net was created first, it would be the forest root and Corp.net's _MSDCS zone would be the only one delegated -- even though they are separate domain trees.
I consider delegating the _MSDCS zone a best practice in DNS design. It ensures better performance for replication, client authentication, Exchange Server and other applications.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.
