Understanding stub zones

54 out of 74 rated this helpful - Rate this topic Updated: January 21, 2005 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Understanding stub zones

A stub zone is a copy of a zone that contains only those resource records necessary to identify the authoritative Domain Name System (DNS) servers for that zone. A stub zone is used to resolve names between separate DNS namespaces. This type of resolution may be necessary when a corporate merger requires that the DNS servers for two separate DNS namespaces resolve names for clients in both namespaces. A stub zone consists of: The start of authority (SOA) resource record, name server (NS) resource records, and the glue A resource records for the delegated zone. The IP address of one or more master servers that can be used to update the stub zone.

The master servers for a stub zone are one or more DNS servers authoritative for the child zone, usually the DNS server hosting the primary zone for the delegated domain name. For more information, see Using stub zones.

Stub zone resolution

When a DNS client performs a recursive query operation on a DNS server hosting a stub zone, the DNS server uses the resource records in the stub zone to resolve the query. The DNS server sends an iterative query to the authoritative DNS servers specified in the NS resource records of the stub zone as if it were using NS resource records in its cache. If the DNS server cannot find the authoritative DNS servers in its stub zone, the DNS server hosting the stub zone attempts standard recursion using its root hints. The DNS server will store the resource records it receives from the authoritative DNS servers listed in a stub zone in its cache, but it will not store these resource records in the stub zone itself; only the SOA, NS, and glue A resource records returned in response to the query are stored in the stub zone. The resource records stored in the cache are cached according to the Time-to-Live (TTL) value in each resource record. The SOA, NS, and glue A resource records, which are not written to cache, expire according to the expire interval specified in the stub zone's SOA record, which is created during the creation of the stub zone and updated during transfers to the stub zone from the original, primary zone. If the query was an iterative query, the DNS server returns a referral containing the servers specified in the stub zone.

Communication between DNS servers hosting parent and child zones

A DNS server that has delegated a domain to a child zone on a different DNS server is made aware of new authoritative DNS servers for the child zone only when the resource records for these new DNS servers are added to the parent zone hosted on the DNS server. This is a manual process and requires that the administrators for the different DNS servers communicate often. With stub zones, a DNS server hosting a

stub zone for one of its delegated domains can obtain updates of the authoritative DNS servers for the child zone when the stub zone is updated. The update is performed from the DNS server hosting the stub zone and the administrator for the DNS server hosting the child zone does not need to be contacted. This functionality is explained in the following example.

The Long and Short of Stub Zones

Stub zones can beef up your DNS infrastructure. Heres 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, Ive 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 dont they show up on the computer screens in Matrix Reloaded ? I dont have an answer to the last question, but lets see if I can clarify a few of the other points.

Whats the Deal with Stub Zones, Anyway?

Heres a fairly common situation. Youre 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. Lets 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

Lets 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 zones Start of Authority (SOA) record. This initial query acts as a functionality check. If one of the servers doesnt respond or responds with a No Record reply, the stub zone server knows not to bother sending it any more queries. 2. Lets 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 wont 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 zones 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. Dont 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 doesnt 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, youll 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:

Contrasting stub zones and conditional forwarders

10 out of 13 rated this helpful - Rate this topic Updated: January 21, 2005 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Contrasting stub zones and conditional forwarders

There can be some confusion about when to use conditional forwarders instead of stub zones because both DNS features allow a DNS server to respond to a query with a referral for, or by forwarding to, a different DNS server; however, these settings are used for very different purposes. These features have the following objectives: A conditional forwarder setting configures the DNS server to forward a query it receives to a DNS server depending on the DNS name contained in the query. A stub zone keeps the DNS server hosting a parent zone aware of all the DNS servers authoritative for a child zone.

Conditional forwarders
In situations where you want DNS clients in separate networks to resolve each others' names without having to query DNS servers on the Internet, such as in the case of a company merger, you should configure the DNS servers in each network to forward queries for names in the other network. DNS servers in one network will forward names for clients in the other network to a specific DNS server that will build up a large cache of information about the other network. When forwarding in this way, you create a direct point of contact between two networks' DNS servers, reducing the need for recursion. Stub zones do not provide the same server-to-server benefit because a DNS server hosting a stub zone in one network will reply to queries for names in the other network with a list of all authoritative DNS servers for the zone with that name, instead of the specific DNS servers you have designated to handle this traffic.

This configuration complicates any type of security settings that you want to establish between specific DNS servers running in each of the networks. For more information, see Understanding forwarders.

Stub zones
Stub zones are used when you want a DNS server hosting a parent zone to remain aware of the authoritative DNS servers for one of its child zones. If the stub zone for a child zone is hosted on the same DNS server as the parent zone, the DNS server hosting the stub zone will receive a list of all new authoritative DNS servers for the child zone when it requests an update from the stub zone's master server . This method of updating the DNS server hosting the parent zone maintains a current list of the authoritative DNS servers for the child zone as they are added and removed. A conditional forwarder is not an efficient method of keeping a DNS server hosting a parent zone aware of the authoritative DNS servers for a child zone. If you used this method, whenever the authoritative DNS servers for the child zone changed, the conditional forwarder setting on the DNS server hosting the parent zone would have to be manually configured with the IP address for each new authoritative DNS server for the child zone. For more information, see Understanding stub zones.