Troubleshooting DNS-Related AD Logon Problems, Part 2

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 acme.com. Because someone else owns the acme.com 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 acme.com'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 acme.com'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 acme.com 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—acme.com, 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 acme.com.

In other words, Dcpromo sets up the DNS server service and the acme.com 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., acme.com), 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 acme.com zone knows about a DC, workstations and other DCs in acme.com can find that DC.