Solving DNS Problems

If you've ever implemented Active Directory (AD), you know that DNS is a necessary evil. DNS is a vital part of AD planning—if you want AD domains, you must first set up DNS. More than almost any other Microsoft tool, AD and its underlying DNS system require planning. The "click first, think later" approach is a prescription for trouble. However, because of some AD-specific needs, making DNS work with AD can be problematic even for a DNS veteran. Let's review some essential principles for making DNS work in support of AD and take a look at some cool new DNS features in Windows Server 2003.

Setting up an AD domain requires first setting up one or more DNS servers to host a DNS zone of the same name. Note my use of the terms domain and zone. Domain can have two different meanings. You can speak of a DNS domain named bigfirm.biz and mean domain in a way that has nothing to do with AD or any Microsoft software. You can also refer to an AD domain named bigfirm.biz—that kind of domain would have little to do with DNS and everything to do with Microsoft security software. To avoid confusing DNS domains with AD domains, I'll use the term zone as a synonym for DNS domain.

Suppose Bigfirm has a DNS server hosting a bigfirm.biz zone. This zone includes a Web server and some email servers that Bigfirm wants its customers to find. However, Bigfirm doesn't want to use that DNS server and that externally hosted bigfirm.biz zone for its AD implementation because AD stores sensitive data that Bigfirm doesn't want to display to the public Internet. Therefore, as most AD designers do, Bigfirm configures a set of DNS servers that aren't visible to the public Internet and that host a bigfirm.biz zone that's separate from the public bigfirm.biz zone. This approach is called split-brain (or split-horizon) DNS.

Split-Brain Essentials
Split-brain DNS is fairly simple to implement, and I've covered it in detail in other articles. (For example, see "Troubleshooting DNS-Related AD Logon Problems, Part 2," February 2002, http://www.winnetmag.com, InstantDoc ID 23565.) To briefly reiterate, to set up split-brain DNS, Bigfirm would first install DNS server software on several servers. Then, Bigfirm would configure every system in its intranet (i.e., the network that will need to find the AD domain controllers—DCs) to consult one or more of those internal servers whenever they need DNS information. DNS clients inside the intranet must never query DNS servers on the public Internet; otherwise, they'll never be able to find the DCs. The same holds true for the internal DNS servers: Configure them to refer only to internal DNS servers for name resolution. (Even though these internal DNS servers look amongst themselves for name resolution, they will be able to resolve names on the Internet.)

Now, Bigfirm can set up one of its internal DNS servers as the primary DNS server for the internal bigfirm.biz zone and configure that zone to permit dynamic updates. Bigfirm would then set up every other intranet DNS server to be a secondary DNS server for the bigfirm.biz zone, each pulling copies of the bigfirm.biz zone from the primary bigfirm.biz server. This simple approach lets you host split-brain DNS for one AD domain.

Adding AD-Integrated Zones
For many people, the preceding summary isn't sufficient because I've left out one important consideration: AD-integrated zones. Using primary and secondary DNS servers for a given zone is the standard way to use DNS servers—a method that the popular BIND DNS server software first used and that Windows 2000 Server's and Windows 2003's built-in DNS server software mimics. This model permits one primary DNS server and an unlimited number of secondary DNS servers for the zone. Any changes to the zone must be made on the primary DNS server, which then copies the changed zone to the secondary servers. In Win2K parlance, you might call this scenario a single-master model because only one of the DNS servers responsible for a zone can accept changes.

The single-master model is a problem for the primary/secondary approach. Because Windows 2003, Windows XP, and Win2K use dynamic DNS (DDNS), every workstation and server attempts to reregister its name and address with its DNS zone every day at boot time. (That's a simplification. Actually, five different events trigger a reregistration.) In the primary/secondary model, only the primary DNS server for a zone can accept changes to that zone. If a firm has several thousand machines, the primary DNS server could find itself assaulted by thousands of DNS registration requests within the space of a few minutes in the morning.

With AD-integrated DNS zones, Microsoft lets you have not just one but many primary DNS servers—the DNS zone information no longer resides in a file on the DNS server but is instead part of the AD database. Because Win2K replicates the AD database to every DC in the domain, every DC can see and even change the DNS information.

AD-integrated zones also secure your network by restricting DDNS registrations to domain members. In a simple primary DNS zone that accepts dynamic registrations, any machine can register DNS records. In theory, then, a rogue machine can register records so that it appears to be a DC. Although the simple act of a system falsely claiming to be a DC wouldn't compromise any data on your network, that prospect isn't exactly pleasing and seems like the first step toward an attempted hijacking of passwords. In an AD-integrated zone, however, a rogue machine would have a more difficult time with such false claims. Before accepting a DNS registration, AD-integrated DNS servers ensure that the machine offering the registration is a member of the domain.

Island DNS
AD-integrated zones and a split-brain DNS design can create a conflict known as island DNS. In an island DNS situation, two or more DCs act as DNS servers for a domain, hosting an AD-integrated zone as usual. However, each DC is aware only of itself. Each DC registers its DC-identification information in its copy of the DNS zone but never replicates that information to the other DC/DNS servers (i.e., servers that do double duty as DCs and DNS servers). Therefore, each DC/DNS server thinks that it's the only one on the planet.

Island DNS happens only on a root domain in a forest, only if you're using AD-integrated zones, only if you're using split-brain DNS (with each DNS server configured to refer only to itself when making DNS queries), and only when you have more than one DC/DNS server for the root domain. As far as I know, island DNS can afflict either Windows 2003— or Win2K-based DNS servers.

You can reconfigure your DC/DNS servers to avoid island DNS. First, choose one DC/DNS system to become a "master" DNS server for the zone. (This server won't truly be a master. DNS registrations remain multimaster, but I use the term as a simple way of expressing the concept.) The master DNS server should still point to itself—meaning that in the system's TCP/IP Properties window, the Preferred DNS server field should contain only that system's IP address. The Alternate DNS server field should be blank. Next, set up the other DNS servers so that they use the master's IP address as their preferred DNS server and some other DNS server as their alternate. Except in the case of the master server, never configure a system to point to itself as either preferred or alternate.

Suppose I have three DCs named DC1, DC2, and DC3. All three DCs are also DNS servers, reside in some forest's root domain, and store that domain's DNS zone information in an AD-integrated zone. After arbitrarily choosing DC1 to be the master, I configure DC1 so that its Preferred DNS server field contains DC1's IP address and leave the Alternate DNS server field empty. I fill in DC2's Preferred DNS server field with DC1's IP address, and in DC2's Alternate DNS server field, I use DC3's IP address. I fill in DC3's Preferred DNS server field with DC1's IP address, and in DC3's Alternate DNS server field, I use DC2's IP address.

Consider a two-DC example—same arrangement, but I have only two DCs: MYDC1 and MYDC2. If I arbitrarily pick MYDC1 as the master, I fill in its Preferred DNS server field with MYDC1's IP address and leave its Alternate DNS server field empty. On MYDC2, I would set the Preferred DNS server field to MYDC1's IP address. But what about MYDC2's Alternate DNS server field? The answer is that you should leave it empty.

Adding More Domains
Now, suppose bigfirm.biz wants to have two AD domains—the original bigfirm
.biz domain and a domain named bigfirm.com. Assuming Bigfirm wants to use split-brain DNS, how does the company accomplish such a configuration? Bigfirm needs only to create a primary zone called bigfirm.com on one of its internal DNS servers. The company would set up every other internal DNS server as a secondary DNS server for the bigfirm.com zone. Bigfirm would then have all the DNS infrastructure it needs for a two-domain AD forest.

If Bigfirm is running AD-integrated zones, the next steps would obviously be to make both bigfirm.biz and bigfirm.com AD-integrated zones, set up some DCs running DNS, and presto—each domain's DNS servers would see the others' zones. However, that procedure wouldn't work because of a quirk in AD-integrated zones. AD-integrated zone data goes only to DCs in that zone's domain—bigfirm.biz DC/DNS servers would see only bigfirm.biz data, and bigfirm.com DC/DNS servers would see only bigfirm.com data. Windows 2003 lets you get past this limitation, as I'll discuss in a future column, but for Win2K-based multidomain forests, you'll need to rearrange things a bit to make AD-integrated DNS work. You'll need to configure all of bigfirm.biz's DNS servers to be secondary DNS servers for bigfirm.com and configure all of bigfirm.com's DNS servers to be secondary DNS servers for bigfirm.biz. Each domain can still use AD-integrated zones inside itself, but each domain must contain the name-resolution information necessary for bigfirm.biz systems to locate bigfirm.com DCs and vice versa.

Bigfirm has more options if adopts Windows 2003—based DNS servers. I'll explore those options another time.