The Island Effect

Reader has trouble with DCs looking within when doing DNS lookups.

• By Bill Boswell
• 04/13/2004

Bill: We have three domain controllers, one in each of three sites. Each DC runs DHCP and DNS. The DNS zone is Active Directory intergated and, to my knowledge, has been working fine. I noticed on Monday that we had many errors in the directory services event log on DC3 referring to the inability to replicate because of a DNS lookup failure. I checked and found out that replication really had failed. I have no idea what caused this. None of our staff were doing anything at the time.

I looked at DNS and discovered a slew of problems. Right now DC1 and DC2 contain DNS info for each other but not for DC3. And DC3 does not contain info for DC1 and DC2, just its own. Also, there were many inconsistences in the _msdcs, _sites, _tcp, and _udp folders. How do I get these three DCs to re-sync this zone?
—David

Get Help from Bill Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to Bill at mailto:[email protected]; the best questions get answered in this column. When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

David: I think you have an example of a rare malady called the "Island Effect." It can happen when the domain controllers in the forest root domain point at themselves for DNS lookups. The cause of the problem lies with the CNAME records that specify the GUID for the domain controllers. These records are absolutely necessary to support replication. Each time a domain controller replicates with another domain controller, it queries the forest root zone looking for the GUID of the domain controller. If that query fails, then replication fails.

In an Active Directory integrated zone, if something happens to delete one of the CNAME records (scavenging, for example, or a replication hiccup) then the domain controller finds itself in a Catch 22. It can't replicate to update the zone with the CNAME record and it can't update the CNAME record until it replicates.

Fortunately, the fix for this is very simple. Just point the domain controllers in the forest root domain at a server other than themselves for DNS lookups. For example, in your three DC configuration, configure the TCP/IP settings for DC1 to use DC2 for DNS lookups. Point DC2 at DC3. Point DC3 at DC1. Virtually immediately, you'll be able to force replication between the DCs.

Microsoft documents this problem in Knowledge Base Article 275278, "DNS Server Becomes an Island When a Domain Controller Points to Itself for the _Msdcs.ForestDnsName Domain." You don't need to worry about this problem in Windows Server 2003. The directory replication agent looks around for another DNS server with a CNAME record if it can't find the record at its primary DNS server.

Hope this helps.

Corrections: In the column, "Exchange 2003 Migration Roadmap" (click here), I made reference to a KnowledgeBase article that was incorrect, it should have been 822179 (the link was correct, but if you were searching TechNet just using only the number, you would have gone nowhere). In that same article, I said that "You can't upgrade an Exchange server directly from Exchange 5.5 to Exchange 2000," but, as you all know, that's a natural migratory progression. It should have said "Exchange 5.5 to Exchange 2003." We regret the error and confusion the small typo may have caused.