The Long and Short of Stub Zones
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
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 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:
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
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
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.
About the Author
Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences.