SQL Server Magazine

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.

   Prev. page   [1] 2     next page