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.
End of Article
Prev. page
1
[2]
next page -->
