Windows Server 2003 DNS

In "Solving DNS Problems," September 2003, I described how to build a DNS infrastructure for a two-domain Active Directory (AD) forest. I said that although Windows 2000–based DNS servers do a pretty good job in multidomain forests, Win2K DNS still lacks a few features. This month, let's look at how Windows Server 2003–based DNS servers can fill the void.

Recall that my simple example comprised a forest with two domains—one named bigfirm.biz and another named bigfirm.com. Both domains use split-brain DNS and must be able to resolve each other's names and SRV records to find domain controllers (DCs) so that systems and users in each domain can authenticate in either domain. Bigfirm could choose between two approaches. The company could create dynamic zones for each domain and not configure them as AD-integrated zones. In that case, Bigfirm would go to every DNS server in the intranet and ensure that every DNS server was either the primary or a secondary server for both the bigfirm.biz and bigfirm.com zone.

Alternatively, the company could make the bigfirm.biz and bigfirm.com zones into AD-integrated zones. AD-integrated zones are typically the best answer for AD zones that use split-brain DNS. Unfortunately, however, Win2K-based DNS servers share a zone's DNS information only with the DCs of that zone's domain. For example, if bigfirm.biz chooses to make its DNS zone AD-integrated, only DNS servers that are also DCs of bigfirm.biz would receive bigfirm.biz's DNS information. Even if you change bigfirm.com's DNS zone so that it's AD-integrated, the bigfirm.com DNS servers will get DNS information only for bigfirm.com, not bigfirm.biz, even though both domains are in the same network. The fix for Win2K-based DNS servers' deafness to any AD-integrated information outside of their domain is to make those DNS servers simple secondary servers for the other servers in the forest.

But suppose Bigfirm has several thousand hosts and a few dozen DNS servers. Every one of those DNS servers acts as a secondary DNS server for at least one zone. Therefore, every time a zone undergoes a change, that information must be transferred to all the company's secondary servers—a bandwidth and CPU burden. Although Microsoft DNS doesn't retransfer the entire zone with every small change—unlike some older DNS software—performing zone transfers the Request for Comments (RFC) way is still inefficient. In contrast, AD-integrated transfers piggyback on AD's more efficient replication engine and benefit from AD's compression of replication traffic between sites. Three ways that Windows 2003 improves on Win2K's DNS servers are stub zones, conditional forwarding, and forestwide AD-integrated zones.

Stub Zones

Stub zones let Windows 2003's DNS server software maintain a different kind of zone than the ones that a standard primary or secondary DNS server holds. Whereas a zone's primary or secondary DNS servers hold entire copies of the zone's zone file, stub-zone servers hold only a minimal zone file. Rather than containing all the zone's records, a stub zone holds only the zone's Start of Authority (SOA) and Name Server (NS) records. In other words, the only information that a DNS server with a stub zone for a given zone can tell you about that zone is the names of its DNS servers and which of those is the primary DNS server for the zone. A stub zone can't provide information such as the IP address of a certain host in the zone.

So, what good is a zone that knows nothing more than which servers are the zone's name servers? Suppose bigfirm.biz has a large zone that contains thousands of records, and that domain's designers want a large number of DNS servers. The designers create a primary DNS server and a bunch of secondary DNS servers. But a network trace shows that the DNS servers are spending more time pulling the latest zone information from the primary DNS server—and thus slowing the primary server and burdening network bandwidth—than they are answering queries. The network's designers must put a zone of some kind for bigfirm.biz on every DNS server in Bigfirm's intranet, but the primary-secondary chatter is wasteful. What's the solution?

The answer is to convert some of the secondary DNS servers to stub-zone DNS servers. When those DNS servers receive a query about bigfirm.biz, they won't have the answer, but they'll immediately know which server to ask, without having to work their way through some DNS server hierarchy to find a source of bigfirm.biz information. The querying DNS server then asks the stub-zone DNS server the question about bigfirm.biz, and the stub-zone server returns the answer. Additionally, the stub-zone servers act as caching servers (as do virtually all DNS servers), so the next person who asks a question about bigfirm.biz will get an immediate answer because the server holding the stub zone can answer the question out of its cache.

A stub zone is small and quickly updated, so it doesn't create much of a RAM or CPU burden for a DNS server. You're accustomed to the idea of placing simple caching servers (i.e., DNS servers with no zones) around your networks to accommodate clients' name-resolution needs, but split-brain DNS requires that each DNS server contain a copy of each AD zone in the forest. Stub zones are the simplest way to fulfill that requirement.

Conditional Forwarding

What if Bigfirm doesn't want to use stub-zone DNS servers? Can the company still place a bunch of DNS servers in its network without making them secondary servers for bigfirm.biz and bigfirm.com? Yes, because Windows 2003's DNS service also offers an approach called conditional forwarding.

In standard DNS forwarding, you configure the DNS server so that if someone queries it about something it can't answer, the server won't search the Internet for the answer. Rather, the DNS server asks another DNS server to find the answer. This notion of one DNS server asking another to do its searching is called forwarding. (You can specify more than one forwarder, but let's keep this example simple.)

With conditional forwarding, you configure the DNS server so that if someone queries it about a particular domain—say, bigfirm.biz—and it doesn't have an answer, it asks another DNS server (its forwarder) to find the answer. Note the difference: Whereas standard forwarding is a broad-spectrum instruction to pose unanswered questions about any domain to a particular DNS server, conditional forwarding says to refer to the forwarder only questions about a particular domain.

More completely, Windows 2003's DNS lets you specify a server or servers to answer queries about a particular domain. So, if Bigfirm wants to roll out 10 secondary DNS servers for bigfirm.biz and bigfirm.com and 100 more DNS servers for resolving internal split-brain DNS requests for bigfirm.biz and bigfirm.com, you'd simply need to set up those 100 DNS servers to conditionally forward all bigfirm.biz queries to the 10 secondary servers.

Admittedly, the differences between stub zones and conditional forwarding are subtle, but they aren't so subtle as to be meaningless. Consider which of the two options automatically updates zone information. Suppose you add a DNS server to a zone. How do you inform a stub-zone server or a server with conditional forwarding of the addition? If you have a stub-zone server, you don't have to do anything—the new server shows up in the stub zone as part of the replication process. But if you have conditional forwarding, you need to visit each DNS server and change its list of servers to forward to in the event of a search for a bigfirm.com record. My understanding is that you can't script this process, either.

Another concern when you compare stub zones with conditional forwarding is permission. Our assumption has been that bigfirm.biz and bigfirm.com are one big happy company, but what if each component keeps an arm's-length distance from the other? In that case, bigfirm.biz servers probably couldn't host stub zones for bigfirm.com servers unless the bigfirm.com folks approved. For the bigfirm.biz servers to pull DNS replication information from bigfirm.com servers, the bigfirm.com servers would need to be willing to transfer that information in a zone transfer. By default, Win2K DNS servers transfer data to any server that asks for it. But Windows 2003–based DNS servers in a zone, by default, perform zone transfers only to servers that have NS records in that zone. Therefore, before a bigfirm.biz DNS server with a bigfirm.com stub zone can update the zone information from a bigfirm.com DNS server, that bigfirm.biz server must have an NS record in bigfirm.com's zone. In contrast, conditional forwarding requires no permission. If someone wanted to configure his or her DNS servers to forward all requests for microsoft.com sites to my DNS server, I couldn't stop him or her. (I don't know why anyone would do such a thing because it would significantly slow down that person's name-resolution process.)

A final consideration regarding stub zones versus conditional forwarding is that, according to Microsoft, a DNS server rereads conditional-forwarding tables with every name resolution. Therefore, a conditional-forwarding table of any length might significantly slow a DNS server's ability to resolve names.

Forestwide AD-Integrated Zones

The third option, forestwide AD-integrated zones, expands the power of AD-integrated DNS zones beyond their Win2K capabilities. AD-integrated DNS zones replicate DNS information among DNS servers that must also be DCs. But AD-integrated information on Win2K servers moves only within a single domain; DNS servers in bigfirm.biz can't see a bigfirm.com AD-integrated zone, and DNS servers in bigfirm.com can't see the AD-integrated bigfirm.biz zone.

In Windows 2003, you can create AD-integrated DNS zones that replicate not only throughout the domain but also throughout the forest. So, you could first set up bigfirm.biz and bigfirm.com as I described last month, with standard primary and secondary servers. Then, after you've established the AD domains and forest, you could simply flip a few switches and instruct all the DNS servers in bigfirm.biz and bigfirm.com to store their DNS information in the forest. Thereafter, AD replication would keep all the DNS servers in sync. However, as you've probably guessed, all your DCs would need to run Windows 2003—at least, that's what my experiments have indicated.

Further Exploration

A fourth way that Windows 2003 improves on Win2K DNS is application partition, which lets you choose which DNS servers get a particular zone's information while letting AD do all the replication. But making that work is a much longer story that we'll leave for another day.