DNS Stub Zones in Windows Server 2003

Stub zones can help reduce the amount of DNS traffic on your network by streamlining name resolution and zone replication. We'll examine how stub zones work, when you would use them, and how to set them up in this tutorial.

Stub zones are a new feature of DNS in Windows Server 2003 that can be used to streamline name resolution, especially in a split namespace scenario. They also help reduce the amount of DNS traffic on your network, making DNS more efficient especially over slow WAN links. This article will look in detail at what stub zones are, how they work, and when to use them. I'll also walk you through the process of creating a stub zone to facilitate name lookups between two separate forests. But first, a little background on DNS zones is necessary to see where stub zones fit into the overall picture.
Types of DNS Zones

A zone is a contiguous portion of DNS namespace managed by one or more name servers. Zones contain resource records that specify the name of the DNS server authoritative for the zone (SOA record), the names and IP addresses of all name servers in the zone (NS records), the names and IP addresses of other hosts (A records), aliases for hosts (CNAME records), and so on.
In the original implementation of DNS found in RFCs 1034 and 1035, two different types of zones were defined:
Primary zones, which store their zone information in a writable text file on the name server.
Secondary zones, which store their zone information in a read-only text file on the name server.
In the implementation of DNS on Windows NT, these two types of zones were referred to as standard zones. A typical scenario for a company that had a single Windows NT domain deployed would involve setting up two name servers on the network, one containing the standard primary zone (the primary name server for the domain) and the other containing the standard secondary zone (the secondary name server). Whenever a new host (for example, a file server) was added to the network, both these name servers had to be updated so clients could find the new host using DNS. To do this, the administrator would create a new A record on the primary name server since the only the primary zone could be modified. The primary name server would then notify the secondary that its records had changed, and the secondary would pull the updated zone information from the primary until it had an identical copy of the primary zone. From the perspective of the secondary name server, the primary name server represents the master name server for this zone.
The main problem with this arrangement was that if the primary name server went down, no changes could be made to the resource records since secondary name servers contained read-only zone information. Also, it meant that all the changes you made to DNS had to be performed on a single name server (the primary), which could be an inconvenience if the company spanned several locations.
Windows 2000 provided a solution to these issues by introducing Active Directory Integrated zones, which stored their zone information within Active Directory instead of text files. The advantages of this new type of zone included using Active Directory replication for zone transfers and allowing resource records to be added or modified on any domain controller running DNS. In other words, all Active Directory Integrated zones are always primary zones as they contain writable copies of the zone database.
Active Directory Integrated zones work well for most Windows 2000-based networks, but they do have some issues. One limitation is if you are dealing with two separate forests (disjointed namespace), a common scenario when companies are merging or form part of a conglomerate. For example, say Company A has close business ties with Company B and employees in Company A need access to resources on Company B's internal network. The usual way of providing them this access would be for the DNS administrator of Company A to add a standard secondary zone on each of Company A's name servers. These secondary zones would then point to name servers on Company B's network as their master name servers, and would obtain their resource records by zone transfers with Company B's name servers. While that works, it's overkill for several reasons. First, it generates a lot of zone transfer traffic between name servers in Company A and Company B, which can pose a problem if the companies are linked together by a slow WAN connection. Second, if Company B decides to decommission one of its name servers without telling the administrator of Company A, some of the secondary zones on Company A's name servers could suddenly find themselves without a master, and once their records expire the Company A clients that use them will no longer be able to access resources in Company B.
What Stub Zones Do

Enter stub zones to the rescue. A stub zone is like a secondary zone in that it obtains its resource records from other name servers (one or more master name servers). A stub zone is also read-only like a secondary zone, so administrators can't manually add, remove, or modify resource records on it. But the differences end here, as stub zones are quite different from secondary zones in a couple of significant ways.
First, while secondary zones contain copies of all the resource records in the corresponding zone on the master name server, stub zones contain only three kinds of resource records:
A copy of the SOA record for the zone.
Copies of NS records for all name servers authoritative for the zone.
Copies of A records for all name servers authoritative for the zone.
That's it--no CNAME records, MX records, SRV records, or A records for other hosts in the zone. So while a secondary zone can be quite large for a big company's network, a stub zone is always very small, just a few records. This means replicating zone information from master to stub zone adds almost nil DNS traffic to your network as the records for name servers rarely change unless you decommission an old name server or deploy a new one. And to make replication even more efficient, stub zones don't use UDP as traditional DNS zone transfers do. Instead, stub zones use TCP, which supports much larger packet sizes than UDP. So while a typical zone transfer might involve many UDP packets flooding the network, stub zone transfer only involves a few packets at most. Also, while most DNS servers can be configured to prevent zone transfers to secondary zones from occurring, stub zones request only SOA, NS, and A records for name servers, all of which are provided without restriction by any name server since these records are essential for name resolution to function properly. Finally, since stub zones can be integrated within Active Directory (secondary zones can't), they can make use of Active Directory replication to propagate their information to all domain controllers on your network.
In our previous scenario, stub zones can be used instead of secondary zones to reduce the amount of zone transfer traffic over the WAN link connecting the two companies. To do this, the administrator for Company A would simply log on to one of the domain controllers, open the DNS console, and create a new stub zone that uses one or more of Company B's name servers as master name servers. By making this stub zone an Active Directory Integrated zone, the stub zone will then be automatically replicated to all other domain controllers on Company A's network. Now when a client on Company A's network wants to connect to a resource on Company B's network, the client issues a DNS query to the nearest Company A domain controller, which then forwards the query to one of Company B's name servers to resolve.