Windows Insider

The Long and Short of Stub Zones

Stub zones can beef up your DNS infrastructure. Here’s a practical guide to when and how to use them.

In a previous DNS column, I briefly covered a new feature in Windows 2003 called stub zones. A stub zone contains Name Server (NS) records from another DNS domain and can be used to augment classic zone delegation. Since that column appeared, I’ve received quite a few requests for more information about how stub zones work. The questions range from “What is the deal with stub zones, anyway?” to “What kind of permissions do I need to create a stub zone?”; and “What if the server where I pull the stub zone goes down?” and “Should I Active Directory-integrate a stub zone?” and “If stub zones are so cool, why don’t they show up on the computer screens in Matrix Reloaded?”

I don’t have an answer to the last question, but let’s see if I can clarify a few of the other points.

What’s the Deal with Stub Zones, Anyway?
Here’s a fairly common situation. You’re the administrator of the root domain in a forest. This puts you in charge of the DNS servers that host the resource records for the root zone of the forest. Let’s call it root.tld. (TLD stands for Top-Level Domain. Examples of TLDs include .com, .edu, .biz, .aero and so on.) You use Windows Server 2003 DNS servers to host the zone.

Another administrator wants to create an AD domain in the same DNS namespace. He proposes the domain name child.root.tld. The administrator wants to integrate the DNS zone for child.root.tld into AD in her domain.

This creates a challenge for DNS clients in root.tld because they need a way to look up records in child.root.tld. You could pull a secondary of the child.root.tld zone to each of your root.tld DNS servers, but zone transfers use bandwidth and the servers might reside on the wrong side of an expensive WAN link.

So, when a DNS client in root.tld requests a resource record from child.root.tld, you need a way to redirect the query to a DNS server that hosts a copy of the child.root.tld zone file. Classic DNS uses delegation to accomplish this task. Delegation creates NS records in the parent domain that identify DNS servers in the child domain. Windows DNS uses a Delegation Wizard for creating these delegation entries.

Delegation has a disadvantage, though. The NS records created by the Delegation Wizard point at specific name servers by IP address. If an administrator in the child domain changes those IP addresses, or renames the DNS servers, or decommissions a server, this creates a lame delegation.

Stub zones help you to avoid lame delegations by creating a zone that contains all the NS records for a specified zone, not just the ones specified for delegation. The stub zone host refreshes the NS list periodically to stay up to date with the current list of name servers for the specified zone. Hence, no lame delegations.

How Stub Zones Get Populated
Let’s say that the child.root.tld zone is hosted by three DNS servers. They could be Windows DNS servers with a single primary master and two secondaries. They could be domain controllers with an AD-integrated zone. Or they could be BIND servers.

You, as the administrator of root.tld, create a stub zone on your Windows 2003 DNS server. During the zone configuration, you specify all three DNS servers in child.root.tld as sources for the zone. See the figure for an example.

Stub zone configuration
Stub zone configuration showing three source DNS servers. (Click image to view larger version.)

The list of source DNS servers forms a preference list, with the first server used to populate the zone, if available. You can move the server name entries up and down to change the preference order. DNS uses this process to populate the zone:

1. First, the stub zone server sends a standard UDP-based DNS query to each of the servers configured in the stub zone configuration. The query asks for the zone’s Start of Authority (SOA) record. This initial query acts as a functionality check. If one of the servers doesn’t respond or responds with a No Record reply, the stub zone server knows not to bother sending it any more queries.

2. Let’s assume that all servers reply to the SOA record request. Next, the stub zone server establishes a TCP connection to port 53 of the DNS server at the top of the preference list for the stub zone.

Using TCP permits the stub zone server to obtain a long list of resource records without concern for the 512-byte UDP datagram size often used by classic DNS servers. Windows 2003 DNS servers support the EDNS0 protocol as defined by RFC 2671, which permits a DNS client and server to negotiate a larger UDP datagram size, but not all DNS servers support this protocol so Microsoft uses TCP to populate a stub zone.

Some firewalls expect DNS queries to only use UDP and won’t permit a TCP connection over port 53. If you experience problems populating a stub zone, check to make sure that the source server accepts TCP-based DNS queries.

3. If the stub zone server is able to make a TCP-based DNS connection, it repeats its query for the zone’s SOA record. The server replies with another copy of the SOA record.

4. The stub zone server then queries the preferred source server for any NS records in the zone. The server replies with all the NS records along with glue records (A records) for each server.

Don’t mistake this NS record query for a standard zone transfer. A zone transfer uses a special DNS opcode (operations code) that requires special permissions at the source server. The stub zone server simply asks for NS records just as any other client might ask.

The stub zone server now has a full complement of NS records for the child.root.tld zone. When a DNS client in root.tld asks for a resource record in child.root.tld, the stub zone DNS server uses these NS records to locate a DNS server in the child.root.tld domain and obtains the requested record from that server on behalf of the client. This recursive query handling is a standard feature of DNS and doesn’t require special configuration of the stub zone.

No Stub Zone Permissions Required
Creating a stub zone requires no admin permissions whatsoever in the source DNS domain. This is because a stub zone contains only SOA, NS, and A records, which are freely available from any DNS server. You can test this yourself by creating a stub zone for a public DNS domain. To do this, you’ll need the IP address of at least one DNS server hosting a copy of the public zone. Obtain this record using the nslookup utility as follows:

nslookup -type=ns

Select one of the NS records returned by this query and use it as the source server when configuring the stub zone.

Once you create the zone, it should take only a few seconds to get a list of NS records and the SOA record from the zone. You may need to press F5 to refresh the DNS management console.

If you select a public DNS domain and the stub zone refuses to populate with records, the owner’s DNS servers or firewalls may not permit TCP queries to port 53. Select another DNS domain. You can use a packet sniffer such as Ethereal or Network Monitor to see if the TCP connections get denied or simply ignored.

The simplicity of configuring stub zones makes them attractive for using DNS to access servers across extranet connections. For example, you might be a vendor who connects to the customer’s system via a special perimeter network. Without stub zones, if your DNS servers get a request for a resource record in the customer’s domain, they would end up querying the customer’s public-facing DNS servers. But by pulling a stub zone from the customer’s internal DNS servers, your recursive queries get resolved using the customer’s internal NS records. Since special permissions aren’t needed to create the stub zone, you don’t need to suffer through endless meetings to get authorization to use this configuration.

How Does a Stub Zone Stay Up To Date?
An SOA record includes a Refresh Interval setting that tells secondary servers how often to pull a zone transfer. By default, Windows DNS assigns a 15-minute refresh interval to SOA records.

A stub zone server doesn’t do classic zone transfers, but does use the same refresh interval. During each refresh, the server requests the NS records from the preferred DNS server in the source domain. If an administrator in the source domain has added a new name server or decommissioned an old server, your DNS server gets the changes and modifies the stub zone accordingly.

What Happens if a Source Server Goes Offline?
You must supply the IP address of at least one DNS server in the source domain to the DNS server hosting the stub zone. If this server goes down, then the stub zone records eventually expire. So, for fault tolerance, you should include multiple source servers in the stub zone configuration.

Here’s how a stub zone uses multiple source servers. When the SOA refresh interval times out, the stub zone server repeats the process of querying each server in the source list with a UDP request. If it gets no response from the server at the top of the preference list, it goes to the next server then the next until it finds one willing and able to accept a TCP-based DNS connection for refreshing the NS record list.

What Happens if all Communication to Source Servers Is Lost?
In this regard, a stub zone behaves just like a standard secondary zone. A DNS secondary zone must get refreshed within a given expiration interval specified in the SOA record. The default zone expiration interval for Windows DNS is one day. If a DNS server can’t refresh a secondary zone or stub zone within this interval, the server stops answering queries for the zone. Clients configured to use that DNS server as their primary server don’t have any other way of finding another DNS server that might have a current copy of the zone. Once their locally-cached resource records begin to expire, any process that relies on DNS name lookups in the source zone will start to fail.

Should I Integrate a Stub Zone into AD?
AD-integrated zones have a lot of advantages, including fault tolerance and reduced network bandwidth. But the primary reason to use AD to host a DNS zone is security for dynamic DNS updates.

A standard primary zone resides in a text file. One server, and one server only, has Read/Write access to that file: The primary master DNS server. The remaining DNS servers either pull secondary copies of the zone via classic zone transfers or act as caching servers. This classic DNS configuration has no mechanism for preventing a rogue machine from dynamically registering thousands of records or overwriting existing records. This is called zone poisoning and it can happen accidentally as well as from a malicious act. When you integrate a zone into AD, the system uses standard object-based security to protect the resource records.

A stub zone doesn’t contain any records that can be dynamically updated. In the example of the root.tld and child.root.tld zones, if a Windows 2000 or Windows XP client in child.root.tld points at a DNS server in root.tld, it won’t attempt to dynamically register its A and PTR records by sending update requests to the root.tld server. Instead, it obtains an SOA record that points at the primary master for child.root.tld and refreshes its records on that server.

That being said, you can save yourself some work by integrating the stub zone into DNS because AD replication will distribute the zone updates to every DC running DNS. And because Windows 2003 DNS permits targeting of DNS zone replication to selected servers based on the naming context that contains the zone records, you have a lot of control over which servers host the stub zone. Flexibility, control and security: all good reasons for using AD-integrated zones for stub zones.

But—and this is a major “but”—to use AD-integrated stub zones, you must deploy at least one Windows 2003 DC and configure the stub zone at that server. This involves updating the AD Schema and making other changes to your forest. This work will probably take you a while to start, even if you begin planning and lab testing immediately.

Will Stub Zones Show up in Matrix Revolutions?
I wasn’t able to find any mention of stub zones in the movie. However, I’m sure that if Neo is indeed the One, he’ll be able to resolve host names into IP addresses for any zone, whether inside or outside the Matrix.

comments powered by Disqus

Reader Comments:

Thu, May 10, 2012 Mark

Thank you for this. I'm working through the MCTS 70-642 Second Edition MS Training Guide by Tony Northrup and JC Mackin. They are absolutely brilliant in knowledge but possibly the worst writers I have tried to read. Their explination of this topic was at best, horrible. You solved my problem for now. Once again, Thank you very much for the articulate explanation.

Sun, Dec 11, 2011 Satish Halemani Bangalore

Excellent article about how stub zones work...until now none of my colleagues were able to answer how it works...but though claiming they knew how it worked :)..Thanks for sharing

Thu, Jun 23, 2011 GM

old post but still VERY helpful

Sun, Sep 20, 2009 Naresh

Very good Explanation. Its been helpful

Fri, Mar 28, 2008 Jason Delaware

thank goodness it was 2 sentences.
Bill, thank you for explaining that. It will help me in my 70-291. Stub zones and delegation are one of the sticking points in the test so even 4 years later this article helps :)

Wed, Oct 31, 2007 Todd from NY Anonymous

I think anyone who uses the words Matrix, Microsoft, BSD, and freedom fighter in the same sentence should really get out a little more.

Fri, Sep 14, 2007 Jim Florida

Good column. It presented the information with an appropriate level of detail and explained the subject effectively. Thanks, it helped.
jim

Mon, Jan 9, 2006 Anonymous Anonymous

The Matrix is well chosen as a metaphor when discussing Microsoft. And of course as a freedom fighter Neo would be using Linux or one of the BSDs.

Sat, Aug 20, 2005 Robert Brinksma The Netherlands

This, for sure, clears up the fogg...

Mon, May 30, 2005 Anonymous Anonymous

good..

Fri, Sep 17, 2004 Anonymous Anonymous

I've searched a clear description between delegation zone and stub zone.
This is a complete and professional explanation.
Good

Tue, Sep 7, 2004 Anonymous Anonymous

very good explanation! Now I understand stub-zones completely -- especially in comparison to a standard-delegation.

Thu, Feb 26, 2004 Anonymous Anonymous

very clear description the new stub feature. also very useful info that stub zone communicate over tcp port 53, didn't found it in a 1000 pages mcp preparation guide

Wed, Jan 28, 2004 Josh Walkerdine Michigan

Good Explanation!

Thu, Jan 22, 2004 alan sacto

This sentence from this article is blatantly misleading:

"This classic DNS configuration has no mechanism for preventing a rogue machine from dynamically registering thousands of records or overwriting existing records. "

Tue, Jan 6, 2004 Anonymous Anonymous

Excellent explanation...

Fri, Jan 2, 2004 AlwaysLearning Chile

Very good explanation.

Wed, Dec 31, 2003 Paresh Vaja London

Good explanation overall. Although at the end references to Schema Update could confuse readers and make them believe that in order to use Stub Zone they have to do Schema Extension to their Forest. This is not entirely correct. because if you already have Windows 2003 Forest - hey presto you have it!

Tue, Dec 23, 2003 Anonymous Anonymous

good Explaination

Tue, Dec 23, 2003 Anonymous Anonymous

very good overview of stub zone. Its a new feature I have yet to get my hands on. But soon, very soon, I will be deploying win2k3 on my company's network.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.