This is one of the more odd things I’ve noticed as a trend in DNS configurations – clear examples of where stub zones should be used, yet I rarely ever see stub zones in environments except for the ones I set them up for.  I suspect it may be because there’s so much widespread misunderstanding of what they are, so people don’t use them, even when they should.  Hopefully, this post might clear up what stub zones are, how they work, and when to use (and not) use them.

What are stub zones?

Stub zones are DNS zones that contain only the SOA, NS, and A glue records for a domain.   Otherwise, they don’t store any other records, such as other A records, PTR records, MX, SRV, TXT, etc.  They’re used to help facilitate name resolution for other domains your DNS servers must resolve that your DNS servers don’t host. Once a stub zone is created on a DNS server, the DNS server connects to the identified DNS server it was told to get the NS, SOA, and A glue records from, and copies down all those records only.  Now, the DNS server knows where to get the name servers responsible for resolving forward lookups for the external domain, so they go there automatically to resolve all records within that domain’s forward lookup zone.  They were added as a feature to Windows 2003 DNS servers to facilitate cross domain DNS name resolution.  You can read Microsoft’s official answer here.

Are stub zones just DNS conditional forwarders/forwarding?

While stub zones and DNS forwarders share the same purpose, they’re not quite the same thing.  DNS forwarding is a simple rule on a DNS server that states “connect to these DNS servers to resolve IP addresses for domain whatever.com”.  They’re static rules that don’t automatically update.  Until Windows Server 2008 and higher, you couldn’t automatically configure all your DNS servers in your domain to use the same forwarding rule, but 2008 did add this ability.  Another important distinction is that forwarding does NOT store DNS zone records, while stub zones do, but don’t let that confuse you from the fact stub zones and forwarding accomplish the same goal, just differently.

Stub zones can also propagate settings effectively like DNS forwarding does with Windows 2008 depending upon how you set the zone up to be stored.  If you use to make the stub zone Active Directory integrated, the zone is stored in AD, and is replicated to at least all the domain controllers in the domain where you created the stub zone, and potentially through the forest.  The key difference between the two in the end as far as functionality is concerned is that stub zones have the distinct advantage of automatically updating what the DNS servers are for the other domain, so long as the administrators of the other domain keep the NS, SOA, and glue A records updated properly.  With forwarding rules, whenever a DNS server for the external domain is added or removed, you must update your forwarding rule, but that’s not the case with stub zones.

When should I use stub zones, and when should I use forwarding?

First off, stub zones are not useful for resolving broadly all internet DNS names.  You use a catch all forwarding rule typically for this, or root hints.  Stub zones (and conditional forwarding for that matter) typically are for situations where you want to resolve DNS names that aren’t on the internet.

With that said, between the two, stub zones are the better choice, provided your DNS environment meets the following:

• All your DNS servers can connect to all the external DNS servers for that other domain.
• There’s no significant advantage to have some of your DNS servers consistently connect to varying DNS servers for the other domain.  For example, if you had let’s say two DNS domains internally for domain1.local and domain2.local, and you had two physical sites, with DNS servers for both domains in both sites, if there’s a compelling reason that DNS servers in site 1 always connect to the DNS servers for the other domain also in site 1, stub zones are not the best solution, because you can’t within a stub zone use such rules to dictate which DNS servers identified stored in the stub zone to use.  Your DNS servers will use any DNS server for the other domain.  In this day and age, DNS traffic isn’t exactly eating up bandwidth, and remember that DNS records are cached anyway, so unless you have a bunch of records with low TTL, this generally doesn’t matter.

Why aren’t stub zones used more then?

I think honestly people just know conditional forwarding works, they understand how it works, so they use it instead, even when stub zones would be the clearly better choice.  I only point out that if name servers may change either by adding or removing them from the external domain, you have to keep on top of that, whereas stub zones would automatically update in those events.  The advantage of stub zones increases the more external domains your DNS servers must resolve other than through internet DNS servers, the more the external domain’s DNS servers change, and the more segregated the management of the DNS servers between the domains are.  For example, if domain1.local’s DNS zones are managed by a different team than domain2.local’s DNS servers, either domain’s admins might not remember to tell the admins of the other domains that DNS servers have changed.  Stub zones would have automatically done that.

Yet, stub zones are consistently the redheaded stepchild in DNS design.  But don’t forget about them.  They’re extremely useful, and we should look to use technologies that can help automate our environments.

What about you?  Do you use stub zones?  Why or why not?