DNS Configuration Errors Breed AD Horror

You say you're having trouble with Active Directory (AD)? A few of your domain controllers (DCs) are having replication trouble and now they're not getting AD updates? Some users are getting No domain controller found errors? Dcpromo is failing for no obvious reason? Have you considered that your problem might not be an AD problem but rather a DNS problem?

A big part of your interactions with AD is finding particular kinds of servers: DCs, Global Catalog (GC) servers, and—if you perform GC replication via SMTP—email servers. If you can't find one of those servers, you can't convince AD to do what you want it to do. AD finds those servers by querying DNS servers—which is why a large proportion of AD failures are caused, at least in my experience, by DNS problems. And most DNS problems stem from the configuration errors that I explain in this article. Let's start with a common problem that plagues folks running a multidomain forest.

An Internal DNS Server Doesn't Contain a Copy of Every Forest Domain
AD needs a DNS infrastructure—that is, a set of DNS servers in your corporate intranet that contain DNS records describing (at a minimum) your DCs and member servers, and probably information about your workstations as well. Computer networks have been using DNS for 2 decades, much longer than they've been using AD, so building a DNS foundation for AD should be simple. However, most DNS infrastructures are designed to be visible to the public Internet, and you certainly don't want your DNS data about AD visible to anyone on the Internet. Therefore, almost all AD implementations' DNS structures are disconnected from the public Internet in a design known as "split-brain DNS," a configuration that comes with requirements you wouldn't see in a vanilla DNS setup.

The most important of those requirements is that every DNS server inside your intranet have a local copy of the DNS information (in DNS parlance, the "DNS zone file") for every domain in your forest. For example, suppose I decide I need only one local domain, perhaps called bigfirm.biz. However, if I think that my enterprise might need to grow, I might decide to hedge my bet by creating not one but two domains: bigfirm.biz and an empty forest root domain that I call root.local. Each AD instance needs a DNS zone, so I'll need DNS zones named root.local and bigfirm.biz.

First, I want to create the root.local domain because it's the forest root domain. To prepare for that, I establish the root.local DNS zone by setting up DNS on a Windows 2003 Server or Windows 2000 machine and creating a zone named root.local on that server. Because the root.local domain has very few machine and user accounts, it's not unreasonable to have a server do double duty as both a DNS server and a DC for root.local. I set up this first server as the primary DNS server for a dynamic zone named root.local, tell the system to use itself as the preferred DNS server, and run Dcpromo to create the AD domain named root.local.

Next, I set up a second server as a secondary DNS server for root.local, again telling that server to use itself as the preferred DNS server. I configure it to go to the first DNS server to get up-to-date copies of the root.local zone. Then, I use Dcpromo to make it not only a second DNS server for the root domain but also a second DC, because having just one DC for any domain—no matter how minor—is a terrible idea.

With two DNS/DC servers in place for root.local, I'm done setting up the forest root domain. However, I'm not suggesting that all DCs should be DNS servers. In a domain that has more than two servers, go ahead and make some servers DCs and others DNS servers, if you prefer. Suppose I've instead decided to make root.local a large domain in a single-domain forest. I would need only to configure all subsequent DNS servers as secondaries on the root.local domain and pull their copy of the root.local zone from root.local's first DNS server, which acts as the primary DNS server of root.local. I'd also need to be sure that any machines that I wanted to be members of the root.local domain pointed to a DNS server that's either the primary or one of the secondaries for root.local.

So far, so good. No configuration problems yet. So, next I tackle my second domain, bigfirm.biz. As with root.local, I set up a server with DNS and create a dynamic zone named bigfirm.biz, point it to itself as a preferred DNS server, and run Dcpromo. But Dcpromo will fail because the DNS service on bigfirm.biz's first (and only) DNS server can't find the root.local zone. The only way a DNS server can find a given DNS zone is either by having a copy of that zone locally on the DNS server's hard disk or by searching the public Internet for a server with that zone. Bigfirm.biz's first DNS server doesn't have a copy of the zone locally, and—by design—it will never find a DNS server with the root.local zone on the public Internet. I specifically didn't want the outside world to find my zone file.

I could make bigfirm.biz's first DNS server a secondary server for root.local, and Dcpromo would work fine. However, the domains in my forest wouldn't find each other. Systems pointing to the DNS servers that are also DCs in root.local would be unable to find bigfirm.biz DCs because root.local's servers would lack a local copy of the bigfirm.biz zone. Worse yet, I might create more DNS servers on systems in the bigfirm.biz zone and remember to make them secondaries on bigfirm.biz but forget to make them secondaries on root.local. That would be bad because the DNS records that identify a domain's all-important GC servers appear only in the DNS zone for the forest root domain. Any systems in a domain other than the forest root would therefore be unable to find a GC, and a host of troubles would await me. To solve this problem, I need to put a bigfirm.biz and root.local zone on every DNS server in the intranet.

The moral of this story: Every DNS server in your intranet must be either a primary or secondary DNS server for each and every domain in your forest.

The Assumption That Integrating All DNS Zones with AD Will Make Everything Work Automatically
But talking about primary and secondary zones is the old pre-Win2K way of thinking about DNS, right? You might argue that a more effective method would be to make the DNS zone Active Directory-integrated. And you'd be right: Active Directory-integrated is often the way to go for AD's DNS infrastructure.

Unfortunately, storing the root.local and bigfirm.biz domains' zones as Active Directory-integrated zones won't solve the problem of DNS servers in root.local that can't find DCs and DNS servers in bigfirm.biz and vice versa. A Win2K Active Directory-integrated zone shares DNS zone information amongst only DCs in that domain—no others. So, if I built root.local and bigfirm.biz with Active Directory-integrated zones, root.local's DNS servers would still know only the root.local information and bigfirm.biz's DNS servers would know only bigfirm.biz's information. I'd still have to visit every root.local DNS server and make it a secondary DNS server for bigfirm.biz, and I'd have to visit every bigfirm.biz DNS server and make it a secondary DNS server for root.local.

By default, Windows 2003­based Active Directory-integrated zones also replicate their DNS information only to DCs in their domain. However, Windows 2003's DNS offers the option to tell an Active Directory-integrated zone to replicate to all DNS servers in the forest.

The moral of this story: Even if you have a forest with more than one domain whose zones are Active Directory-integrated, you still have to either ensure that all DNS servers in a domain are secondary DNS servers for the zones of all other domains (if the domains use Win2K) or use Windows 2003 and tell the zones to replicate to the entire forest.

A Workstation or Server Points to a DNS Server Outside the Network
A workstation or server that points to a DNS server outside the network is probably the most common DNS configuration error. As I mentioned, nearly every AD implementation needs a DNS infrastructure that isn't visible from the public Internet. Bigfirm might well have a DNS zone named bigfirm.biz that someone can easily find from the public Internet, but the bigfirm.biz DNS zone that supports the bigfirm.biz AD domain shouldn't show up on an Internet query. If someone connected to the Internet via a cable modem used Nslookup to perform a query about bigfirm.biz, that query should return information about the public bigfirm.biz zone—not the AD-serving zone.

Therefore, any system that needs to access the bigfirm.biz AD domain absolutely must address its DNS queries to one of the DNS servers that are "in on the secret"—that is, the intranet DNS servers that contain a copy of the internal AD-serving bigfirm.biz zone. Querying a DNS server that doesn't contain a copy of the AD-serving zone would cause that DNS server to search the Internet for the answer to a query such as, "What are the names of Bigfirm's DCs?" And, if I've set up DNS correctly, no public DNS server can answer that question.

The Windows GUI for TCP/IP lets you tell your system the IP addresses of two DNS servers: the preferred DNS server and the alternate DNS server. When a client system performs DNS queries, it will first try DNS queries to the preferred IP address; if nobody's home, the client will try the alternate address. (You can configure as many as six more alternates through either the registry or a server running Microsoft's DHCP Server service.) The preferred, alternate, and any other potential alternate DNS servers must be intranet DNS servers for each computer in your intranet.

How might a misconfiguration at this point cause a problem? When configuring preferred and alternate DNS servers, some people think, "Boy, I'll be in big trouble if all my internal DNS servers are down." Therefore, they configure their systems so that the preferred DNS server is an intranet DNS server but configure the alternate server with the IP address of a DNS server on the Internet—perhaps their ISP's DNS server. That scenario leads to a perplexing error: When the preferred DNS server responds to the client's request for information about AD, it gets an answer, but when the client queries the alternate server, the alternate server can't help. Thus, the client can get to AD some of the time but not all the time.

Worse, many people get confused about designating preferred and alternate DNS servers. Which DNS server should a given DNS server query when asking a DNS question? Again, the answer is that, inasmuch as your DNS server needs to be able to find systems in AD, both the preferred and alternate DNS servers (and any other alternates that you specify) should always be intranet DNS servers. In fact, configuring intranet DNS servers to use themselves as preferred DNS servers is typically fine, and I usually don't configure an alternate for a DNS server. If a DNS server fails, a big problem is almost
certainly in need of fixing, and that server probably doesn't really need to resolve any system names until I get the DNS Server service back up and running.

The moral of this story: No matter how many DNS servers you tell a system about, they should all be intranet DNS servers. And when you're configuring intranet DNS servers, configure them to refer to themselves.

A Win2K DNS/DC System Points to Itself
I just told you to configure intranet DNS servers to refer to themselves, but you might find yourself with a special case—running a Win2K-based AD implementation and configuring your forest's root domain as Active Directory-integrated. For a DNS server to host an Active Directory-integrated zone for a forest root, that DNS server must be both a DNS server and a DC for the forest root domain. Now, if you configure all your DNS/DC systems to use themselves as preferred DNS servers, you'll get a problem called "island DNS," in which each of those DNS servers loses the knowledge of any other DNS server but itself. For more information about this error, see the Learning Path box, page 46.

To fix this problem, you can either upgrade your DCs to Windows 2003, which doesn't have this problem, or elect not to use Active Directory-integrated zones on the root domain. (Remember, only the root domain can experience the problem.)

You can also work around the problem as follows: Choose a DNS server to be the "master" DNS server. Then, configure a preferred DNS server for this server, and point it to itself. Finally, have the other servers all point to this DNS server as their preferred DNS server. You can configure alternate DNS servers for any DNS server except the "master," but never point any of the DNS/DC servers to themselves.

The moral of this story: If you're using Active Directory-integrated zones on Win2K-based DCs in a forest root domain, don't point DNS servers to themselves. (This problem doesn't affect Windows 2003-based systems.)

An Old HOSTS File Keeps You from Finding a Server
Recently, a reader asked for my help with a mysterious DNS problem. One computer—only one!—in his intranet couldn't connect to a particular DC. The computer had no troubles with other DCs in the network, and no other systems had trouble connecting to this DC. What was the trouble?

I ran through a list of possible problems and solutions, but none helped. Unhappily, I admitted that I was out of ideas. He emailed me back a few weeks later with the answer: a HOSTS file!

In winntsystem32driversetc (on Win2K systems) or windowssystem32drivers (on Windows XP and Windows 2003 systems), you'll find a text file named HOSTS (no file extension). Before DNS, HOSTS files answered such questions as "What's the IP address of a machine with this name?" HOSTS is just a simple list of IP address/computer name combinations and explanatory comments starting with a number sign (#). HOSTS is largely unused now save for the occasional troubleshooting need, but every TCP/IP stack I've ever seen still supports HOSTS. Your HOSTS file probably contains only one non-comment line—"127.0.0.1 localhost"—which will cause your system to recognize the name "localhost" as itself. (The IP address 127.0.0.1 is the special IP "loopback" address, so pinging "localhost" causes your system to ping itself.)

However, suppose you had a local DC called dc4.bigfirm.biz at 192.168.4.2. If you queried a DNS server for the IP address of dc4.bigfirm.biz, you'd get an answer of 192.168.4.2. But now suppose that someone has put a record such as 10.0.0.5 dc4.bigfirm.biz in your client PC's HOSTS file. Whenever your system tries to resolve the name dc4.bigfirm.biz, your client PC might get two answers: 192.168.4.2 from DNS and 10.0.0.5 from HOSTS. Who wins? HOSTS. In fact, your system first asks HOSTS, and if HOSTS has an answer, your system doesn't even bother checking with DNS. For some reason, the aforementioned reader's PC had a HOSTS file entry that referred to the DC in question, but the HOSTS file had the wrong IP address for that DC.

The moral of this story: When just one system has trouble finding a particular server and no other system has that trouble, look at the troubled system's HOSTS file.

Dcpromo Did the Work
Here's a typical email note: A reader has created an AD implementation with one DC, and that DC works fine, but the reader can't get AD to join any workstations to the domain, nor can the reader get Dcpromo to run on another server to add a second DC. The problem? Dcpromo strikes again.

Dcpromo checks whether you have a sufficient DNS infrastructure—that is, a zone whose name matches your AD implementation's name and that accepts dynamic DNS registration—before it sets up AD. That's a good move, and I'm glad Microsoft designed Dcpromo to perform that check. Unfortunately, the company went further and designed Dcpromo to offer to set up DNS for you. Never let Dcpromo set up DNS. Dcpromo doesn't point the first DC to itself, nor does it instruct you to point all your internal systems to intranet DNS servers, nor does it address any of the other items covered in this article.

The moral of this story: If Dcpromo complains that DNS isn't correctly set up, your best bet is to stop Dcpromo and recheck your DNS infrastructure. You don't want to create an AD implementation atop a wobbly DNS foundation.

Avoid AD Horror
DNS provides a simple function in your network: It connects machines' names and their IP addresses. AD adds to DNS's task the job of keeping lists of DCs and GC servers. But the simplicity of those tasks belies their importance. Without DNS, AD simply won't function. Keep an eye out for these common DNS configuration problems, and your DNS implementation will be trouble-free.