At work there was some confusion that creating stub zones requires the master servers to allow zone transfers to the servers holding the stub zones. That’s not correct and oddly I couldn’t find any direct hits when I typed this query into Google so I could show some blog posts/ articles for support.
I mentioned this briefly in one of my earlier blog posts. But don’t take my word for it here are two blog posts and a book except mentioning the same:
- The Long and Short of Stub zones
- Conditional Forwarders and Stub Zones in Windows
- And read the section called “Manage stub zones” in this book
If stub zones don’t require any zone transfers what’s the difference between them and conditional forwarders? Again, check the second link above but the long and short of it is that stub zones query the master server IPs you give and asks these servers for a list of NS records and their addresses, and then queries these name servers for whatever record you want; while conditional forwarders have a predefined list of name servers and so always query these for the record you want. Stub zones are more resilient to changes. If the remote end adds/ removes a name server the stub zone will automatically pick it up as long as the master servers are up-to-date and reachable. A conditional forwarder won’t do this automatically – the remote end admins will have to communicate the new name server details to the conditional forwarder admins and they will have to update at their end.
Hope that clarifies!
p.s. See my next post.
p.p.s. Hadn’t thought of this. Good point (via):
Stub zones: will use whatever is in the NS records of the zone (or descendants of the zone, if not otherwise defined) to resolve queries which are below a zone cut.
Forward zones: will always use the configured forwarders, which must support recursion, even for names which are known to be deeper in the delegation hierarchy and whose delegated/authoritative nameservers might respond more quickly than the forwarders, if asked.