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.

• By Bill Boswell
• 01/01/2004

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 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.