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.

   Previous  [1]  2  Next