AD DNS Stub Zones, Conditional Forwarders, and Zone Delegation
2009-09-08 Initial Post
Windows Server 2003/2008
STUB ZONES AND CONDITIONAL FORWARDERS
I’ve been working with AD for 9 years and just recently really understood what a stub zone was and which situations are appropriate for its use. I also came to a similar realization about conditional forwarding, although I was already more familiar with that. Anyway, I don’t think many people really understand these features for two major reasons:
1.) Both features were new in Windows Server 2003.
2.) Unless there are a lot of mergers, very specialized DNS requirements, or multiple-domain forests, the average AD admin probably wouldn't know much about stub zones or conditional forwarding other than having read about them somewhere.
Both methods are useful for resolving names in a disjointed namespace scenario, such as when two firms merge. Based on what I’ve read, stub zones are better to use in this scenario since they automatically update the list of valid NS (Name Server) records for the stub zone. Also, if the stub zone is AD-integrated, it automatically gets replicated to all AD/DNS servers.
Conditional forwarders are created individually on each DNS server, but you do have the option with 2008 to make each conditional forwarder AD-integrated and hence replicate the conditional forwarder data to other DNS servers.
Note that you can also use regular forwarders in a merger scenario, but regular forwarders are not specific to a domain like conditional forwarders are, so you wouldn’t want to use them since they'd be used to resolve Internet hostnames as well.
The two articles below explain stub zones and conditional forwarders and also compare them. These were the best articles that I found on their respective topics.
http://www.windowsnetworking.com/articles_tutorials/DNS_Stub_Zones.html
http://www.windowsnetworking.com/articles_tutorials/DNS_Conditional_Forwarding_in_Windows_Server_2003.html
ZONE DELEGATION
Delegation is used to delegate management of a subdomain zone to another DNS server and is useful in contiguous namespace scenarios. In AD, delegation can be used when setting up a new AD child domain. The DC/DNS setup process for the child domain automatically creates a delegated zone for the child domain within the parent zone on the parent AD domain.
The NS records in the delegated zone point to the child domain’s DNS servers. So if a client in the parent domain were to query a DNS server in the parent domain for a resource in the child domain, the parent domain’s DNS server would refer the client to the NSes in the delegated (child) zone.
The delegated zone shows up under the parent zone as a gray folder. For example, I have a root domain named corp-ad.local. I created that domain with AD-integrated DNS and hence a zone named corp-ad.local was created.
I then set up a new AD child domain named sub-ad-1.corp-ad.local. During setup, I chose to set up DNS on the DC and use AD-integrated DNS (same as when I set up the parent domain). The dcpromo process then created a delegated zone named sub-ad-1 underneath the parent domain corp-ad.local. The new child domain DC/DNS server shows up as an NS in the delegated zone.
Another thing I noticed was that on the sub-ad-1 DC/DNS server, its forwarder was set up to use the parent DNS server (I’m guessing this was because I had the parent DNS server as the primary DNS server before I ran dcpromo on the child domain DC). This allows the child domain to resolve names in the parent domain. And the delegated zone for the child domain in the parent domain allows the parent domain to resolve names in the child domain.
This all works for name resolution between both domains, but I think using stub zones for both domains would work better. I changed the default settings and used stub zones in both domains and they worked fine. I’m not sure exactly which method is more efficient though, or why Microsoft would use zone delegation and forwarders by default. NOTE: I tested all this with Windows Server 2008, but 2003 should work similarly.
Also see http://technet.microsoft.com/en-us/library/cc784494(WS.10).aspx.
