Troubleshooting DNS-Related AD Logon Problems, Part 1

Now let's ask Nslookup to simulate using a local DC to log on. You'll need to know the name of your domain and your AD site. You'll always have at least one site: When you create the first DC in a forest, Dcpromo creates a site called, by default, Default-First-Site-Name. Type the Nslookup command on a command line. At the prompt, enter two commands, using the syntax

set type=srv
_kerberos._tcp.<SiteName>
    ._sites.dc._msdcs.
    <DomainName>

Be sure to include the underscores, and type the second command on one line without spaces. For example, for a site named HQ in the acme.com domain, you'd type

set type=srv
_kerberos._tcp.hq._sites.dc
  ._msdcs.acme.com

If you type the commands correctly, you might get a response like the one Figure 1 shows (don't worry if you don't—that's why we're troubleshooting). But if those commands don't work for you, then Dcpromo won't be able to log on either. Dcpromo would then say to DNS, "Tell me about all the DCs in the world for acme.com." You can also use Nslookup to simulate that query:

_kerberos._tcp.dc._msdcs
   .acme.com

But if your first query failed, this one likely will too, leading to a message resembling ns1.yourisp.com can't find kerberos._tcp.dc._msdcs.acme.com: Non-existent domain.

The reason for this problem in most test networks is that your AD domain (e.g., acme.com) has the same name as a registered Internet domain, and that name conflict poses problems. To see why, let's roll back the clock to when you created the first DC in your test forest.

The Origin of the Problem
When you use Dcpromo to create a new forest with a first domain named acme.com, Dcpromo needs to write several records into the writable copy of the acme.com zone, which lives on the domain's primary DNS server. So, Dcpromo queries the local DNS server for the address of the primary DNS server for acme.com. Because you're just playing around from home, your Win2K server likely connects to the Internet through DSL or a cable modem and thus points to some DNS server on the Internet. That DNS server happens to know about a registered Internet domain named acme.com and responds that the primary acme.com server is some UNIX box on the Internet.

Dcpromo then says to that distant server, "Hi. I'm about to write a bunch of new SRV records to you with dynamic DNS (DDNS). That's all right, isn't it?" The UNIX server responds, "No! I don't know you, and I'm not about to let you write records into my zone." That response, of course, leaves Dcpromo in a quandary.

Instead of telling you that it has found the acme.com DNS server but the server doesn't accept updates, Dcpromo fibs by reporting that it couldn't find the DNS server for acme.com and offers an alternative: "Would you like me to configure a DNS server for this domain?" You say "Yes," grateful that Dcpromo is such a can-do kind of program. So, Dcpromo sets up the soon-to-be DC as a DNS server, creates an acme.com zone on that server, uses that zone to set up acme.com, then reboots.

That's when the trouble starts, as I'll explain in my next column. See you then.