Skip navigation

Troubleshooting DNS-Related AD Logon Problems, Part 2

AD logons and split-brain DNS

In "Troubleshooting DNS-Related AD Logon Problems, Part 1," November 15, 2001, InstantDoc ID 22774, I started discussing how mistakes that you might easily make in DNS can cause Active Directory (AD) domain logons to fail. As I explained, for many new AD domains the trouble starts when you run Dcpromo, which needs to find the primary DNS server for the DNS domain whose name matches the name of your AD domain.

To recap, I noted that in both large-scale domains and small test domains, you often try to fool DNS so that you can create an AD domain with a name that matches another domain on the Internet—perhaps even your own public Internet domain, if you're implementing split-brain DNS. (For an explanation of split-brain DNS, see "DNS and Active Directory," July 2001, InstantDoc ID 21128.) For example, suppose that you create a small AD test domain named Because someone else owns the domain, a DNS search on the Internet turns up a UNIX-based DNS server. When Dc-promo asks that server whether it accepts dynamic updates—as any DNS server that serves an AD domain must—the real's DNS server, not surprisingly, says, "No, of course I don't!"

Rebuffed, Dcpromo asks you what to do. Rather than tell you that it found a DNS server but that the server won't accept dynamic updates, Dcpromo says it couldn't find's DNS server. (To anyone from Microsoft who might be reading this column, I suggest fixing this Dcpromo behavior in Microsoft .NET Server.) Dcpromo then offers to set up your DNS server service on that UNIX server and to configure it as the DNS server for your local domain. Most folks accept the offer, and as I said in my earlier column, that's where the problems start.

A Lack of Communication
When setting up a local DNS server, Dcpromo creates a zone with the same name as the domain—, in my example. Thus, when you create a new AD domain, your computer serves two functions: It's both the first domain controller (DC) and the DNS server for the domain. But because Dcpromo never tells the DC software that the DNS software exists on the same computer, the DC still can't find a DNS server that will accept dynamic updates for

In other words, Dcpromo sets up the DNS server service and the zone but doesn't tell the computer's TCP/IP stack to refer to itself when looking for a DNS server. The DNS server is running, but no computer—not even the computer that the DNS server is running on—knows that it needs to refer to that DNS server first when looking for a domain. So, Dcpromo completes the basic domain setup, then asks for and receives permission to reboot the computer.

As it reboots, the computer sets up a TCP/IP stack just as you had set up the stack before you made the computer a DC. At that time, you used DHCP either to configure the stack or set it up statically. If you used DHCP, the DHCP server is either your ISP's DHCP server or your corporate DHCP server. Regardless, the DHCP server is unlikely to tell your computer to use itself as a preferred DNS server. If you originally configured your TCP/IP stack statically, did you tell the computer to use itself as a preferred DNS server? Probably not. (But if you did, congratulations—good work!)

As a result, when the computer boots, its DHCP or static configuration tells the computer to use some DNS server other than itself—probably some server on the Internet. Then, the Netlogon service swings into action.

As on Windows NT 4.0, Netlogon on Windows 2000 is an important service that runs only on DCs. Among Netlogon's first duties are to locate the primary DNS server for its domain (e.g.,, then to use dynamic DNS (DDNS) to write the server identification (SRV) and host name (A) records for Netlogon into the domain's zone. The Netlogon service on each DC periodically reintroduces itself to the domain's DNS zone so that DNS knows about that DC. After the zone knows about a DC, workstations and other DCs in can find that DC.

But when the DC's TCP/IP stack points to a DNS server other than itself, a query for the primary DNS server ends up on the public Internet's DNS servers and returns the address of the DNS server for the registered domain. When Netlogon tries to write records to that UNIX DNS server, the server refuses the updates and Netlogon reports the problem in the System log as event ID 5773: The DNS server for this DC does not support dynamic DNS. Add the DNS records from the file '%SystemRoot%\System32\Config\netlogon.dns' to the DNS server serving the domain referenced in that file.

If you can't convince a workstation to log on to a new AD domain or if Dcpromo refuses to run on a second machine that you intend to be another DC in your domain, check the System log for event ID 5773. If Dcpromo told you that it would configure DNS for you, event ID 5773 is proof that you need to point your DC's TCP/IP stack to itself.

For further proof, start up the Microsoft Management Console (MMC) DNS snap-in, double-click the icon for your server, open the Forward Lookup Zones folder, then double-click the folder for your domain. A folder that contains only two or three records and no other folders indicates that Netlogon couldn't find the DNS server that's running on the same computer as Netlogon. Configure your computer's TCP/IP settings to point to your computer as the preferred DNS server, restart Netlogon, then again check the folder for your domain; it will contain four folders full of find-a-DC information.

Adding a Second DC
But you're still not out of the woods. Your first DC can now find itself, but a second DC won't be able to find the first one. After you put Win2K on a second machine and join that machine to, you need to configure that machine's TCP/IP stack to look to the first machine as its preferred DNS server. You can do the same for any systems that you want to make into additional DCs.

If you want your network to grow, you can make a few more Win2K servers into DNS servers for Because Dcpromo automatically makes the zone into an AD-integrated zone, you can use only DCs as DNS servers. If you don't want an AD-integrated zone—perhaps because you want to use non-DCs as DNS servers in the domain—you can convert the AD-integrated zone into a standard primary zone with a few clicks. Simply open the DNS snap-in, double-click the DNS server's icon, then open the Forward Lookup Zones folder. Inside, you'll see a folder labeled with your domain name. Right-click that folder, choose Properties, then click the General tab. Click Change and select Standard primary instead of Active Directory-integrated.

Building It Right
By now, our DNS infrastructure is in pretty good shape. Let's look at how to expand it to larger networks. But instead of letting Dcpromo discover that a problem exists with DNS, let's make sure that DNS works from the start.

Suppose you actually work for and are going to set up AD for the company. Would that be a simpler scenario? You'd just replace the existing DNS servers with servers that accept dynamic updates, right? Probably not. AD stores information in a DNS zone that you might not be comfortable advertising on the public Internet. So even if you work for, you'd still want to fake out AD by letting it use an internal-only DNS, thereby causing AD to leave the publicly visible DNS untouched. Such a setup is called split-brain DNS and is a good idea for any enterprise, security-wise. Suppose Acme's ISP hosts the publicly visible zone. Here's how you'd set up an internal-only DNS for's AD.

First, set up at least one more DNS server on the intranet. On the first server that you set up, make the DNS zone a standard primary zone and enable dynamic updates. On any subsequent servers, set up as a standard secondary zone. (You can even use NT 4.0 servers as secondary DNS servers in AD, provided that those NT servers run Service Pack 6a—SP6a.) Configure the TCP/IP stacks on each workstation and server in your intranet to use one of your internal DNS servers as the preferred DNS server and another DNS server as the alternative DNS server.

Now, when you run Dcpromo, it will find the DNS server that you want it to find—your internal DNS server—and will set up AD correctly. Workstations and servers will be able to find that DC to log them on, and when you run Dcpromo on other systems to create additional DCs, Dcpromo will run fine. After you set up AD, you can shift your zone to AD-integrated.

Now that you have two sets of books DNS-wise, you have only one more thing to do. If someone inside Acme tries to find, that user will always find the zones on the intranet server and won't be able to find the public zone. So, be sure to manually copy the records in the public zone to the intranet zones. If you don't, you'll discover that the only people who can't see Acme's Web site are the people inside Acme, which makes for a strange situation.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.