The Island Effect
Reader has trouble with DCs looking within when doing DNS lookups.
- By Bill Boswell
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?
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:firstname.lastname@example.org;
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
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
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.
Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences.