In "Solving DNS Problems," September 2003, http://www.winnetmag.com, InstantDoc ID 39771, 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.
Prev. page
[1]
2
next page 
