Windows Server 2003 : Deploying Stub Zones - Benefits of Stub Zones, Stub Zone Updates

Understanding Stub Zones

When you configure a new zone using the New Zone Wizard, you have the option of creating the new zone as a primary, secondary, or stub zone. When you create a stub zone, a zone is configured that maintains only those records—NS resource records—needed to locate the name servers of the master zone specified by the name of the stub zone.

Stub zones are used to keep all the NS resource records from a master zone current. To configure a stub zone, you need to specify at least one name server, the master, with an IP address that doesn’t change. Any new name servers you add to the master zone later are updated to the stub zone automatically through zone transfers.

You cannot modify a stub zone’s resource records. Any changes you want to make to these records in a stub zone must be made in the original primary zone from which the stub zone is derived.

Benefits of Stub Zones

Stub zones allow you to achieve the following benefits:

• Improve name resolution Stub zones enable a DNS server to perform recursion by using the stub zone’s list of name servers without querying the root server.

• Keep foreign zone information current By updating the stub zone regularly, the DNS server hosting the stub zone maintains a current list of name servers for a different zone, such as a delegated zone on a different DNS server.

• Simplify DNS administration By using stub zones throughout your DNS infrastructure, you can distribute zone information without using secondary zones.

  Important

  Stub zones do not serve the same purpose as secondary zones and are not an alternative when planning for fault tolerance, redundancy, or load sharing.

  
  

When To Use Stub Zones

Stub zones are most frequently used to keep track of the name servers that are authoritative for delegated zones. Most often, stub zones are hosted on the parent DNS servers of those delegated zones.

A DNS server that has delegated a child zone to a different DNS server is usually informed of new authoritative DNS servers added to the child zone only when the resource records for these new DNS servers are manually added to the parent zone. With stub zones, a DNS server can host a stub zone for one of its delegated (child) zones and obtain updates of that zone’s authoritative servers whenever additional name servers are added to the master zone. This functionality is explained in the following example, illustrated in Figure 1.

Figure 1. Stub zones and delegations

Stub Zone Example

A DNS server that is authoritative for the parent zone microsoft.com delegated a child zone, widgets.microsoft.com, to separate DNS servers. When the delegation for the child zone widgets.microsoft.com was originally performed, it contained only two NS resource records for the widgets.microsoft.com zone’s authoritative DNS servers. Later, administrators of this zone configured additional DNS servers as authoritative for the zone but did not notify the administrators of the parent zone, microsoft.com. As a result, the DNS server hosting the parent zone is not informed of the new DNS servers that are authoritative for its child zone, widgets.microsoft.com, and continues to query the only two authoritative DNS servers that exist in the stub zone.

You can remedy this situation by configuring the DNS server that is authoritative for the parent zone, microsoft.com, to host a stub zone for its child zone, widgets.microsoft.com. When the administrator of the authoritative DNS server for microsoft.com updates the resource records for its stub zone, it queries the master server for widgets.microsoft.com to obtain that zone’s authoritative DNS server records. Consequently, the DNS server that is authoritative for the parent zone learns about the new name servers that are authoritative for the widgets.microsoft.com child zone and is able to perform recursion to all the child zone’s authoritative DNS servers.

Important

A stub zone cannot be hosted on a DNS server that is authoritative for the same zone. For example, the stub zone for widgets.microsoft.com cannot be hosted on a DNS server that is authoritative for widgets.microsoft.com. The stub zone for this domain can be hosted on a DNS server that is authoritative for a different zone, such as a parent zone containing a delegation for widgets.microsoft.com. If the microsoft.com zone contained a delegation to widgets.microsoft.com, the DNS server hosting microsoft.com could also host a stub zone for widgets.microsoft.com.

Other Uses for Stub Zones

You can also use stub zones to facilitate name resolution across domains in a manner that avoids searching the DNS namespace for a common parent server. Stub zones can thus replace secondary zones in cases where achieving DNS connectivity across domains is important but providing data redundancy for the master zone is not. Also note that stub zones improve name resolution and eliminate the burden to network resources that would otherwise result from large zone transfers.

Figure 2 illustrates using stub zones to facilitate name resolution in this way. In the example, a query for the host name ns.mgmt.ldn.microsoft.com is submitted to two different name servers. In the first case, the server authoritative for the mfg.wa.microsoft.com domain accepts the query. Many other name servers must then be contacted before the destination name server that is authoritative for the appropriate domain (mgmt.ldn.microsoft.com) receives the query. In the second case, the DNS server that is authoritative for the actg.wa.microsoft.com domain receives a query for the same name, ns.mgmt.ldn.microsoft.com. Because this second server also hosts a stub zone for the destination mgmt.ldn.microsoft.com, the server already knows the address of the server that is authoritative for the record for the host ns.mgmt.ldn.microsoft.com, and it sends a recursive query directly to the authoritative server.

Figure 2. Using stub zones across domains

Stub Zone Resource Records

A stub zone contains SOA, NS, and A glue resource records for authoritative DNS servers in a zone. The SOA type identifies the primary DNS server for the actual zone (master server) and other zone property information. The NS resource record type contains a list of authoritative DNS servers for a zone (primary and secondary servers). The A glue resource records hold the IP addresses of the DNS servers authoritative for the zone.

Note

As with delegations, stub zones contain glue records in the zone data, but these glue records are not visible in the DNS console.

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 stub zone’s resource records to resolve the query. The DNS server then queries the authoritative servers specified in the stub zone’s NS resource records. If the DNS server cannot find any of the authoritative name servers listed in its stub zone, it attempts standard recursion.

The DNS server stores the resource records it receives from a stub zone’s authoritative servers in its cache and not in the stub zone itself; only the SOA, NS, and 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 A resource records, which are not written to the cache, expire according to the interval specified in the stub zone’s SOA resource record, which is created during the creation of the stub zone and updated during transfers to the stub zone from the original primary zone.

When a DNS server receives a query for which recursion has been disabled, the DNS server returns a referral pointing to the servers specified in the stub zone.

Stub Zone Updates

When a DNS server loads a stub zone, it queries the zone’s master server for the SOA resource record, NS resource records at the zone’s root, and A resource records. During updates to the stub zone, the master server is queried by the DNS server hosting the stub zone for the same resource record types requested during the loading of the stub zone. The SOA resource record’s refresh interval determines when the DNS server hosting the stub zone attempts a zone transfer (update). Should an update fail, the SOA resource record’s retry interval determines when the update is retried. Once the retry interval has expired without a successful update, the expiration time as specified in the SOA resource record’s Expires field determines when the DNS server stops using the stub zone data.

You can use the DNS console to perform the following stub zone update operations:

• Reload This operation reloads the stub zone from the local storage of the DNS server hosting it.

• Transfer From Master The DNS server hosting the stub zone determines whether the serial number in the stub zone’s SOA resource record has expired and then performs a zone transfer from the stub zone’s master server.

• Reload From Master This operation performs a zone transfer from the stub zone’s master server regardless of the serial number in the stub zone’s SOA resource record.

Practice: Deploying a Stub Zone

In this practice, you create a stub zone on Server01 that pulls transfers from the delegated subdomain sub.contoso.com.

Exercise 1: Creating a Stub Zone

1.	Log on to Server02.
2.	Open the DNS console, and add Server01 to the console so that you can administer both Server01 and Server02.
3.	Expand the Server02 node, expand Forward Lookup Zones, and select sub.contoso.com.
4.	Right-click sub.contoso.com in the tree pane, and click Properties.
5.	Click the Name Servers tab.
6.	Click Add. The New Resource Record dialog box appears.
7.	Type server01.contoso.com in the Server Fully Qualified Domain Name (FQDN) box.
8.	Click Resolve. Confirm that Server01’s IP address, 192.168.0.1 appears in the IP Address box.
9.	Click OK to close the New Resource Record dialog box.
10.	Click OK to close the sub.contoso.com zone properties dialog box.
11.	Expand the Server01 node, right-click the Forward Lookup Zones node, and select New Zone. The New Zone Wizard launches.
12.	Click Next. The Zone Type page appears.
13.	Select Stub Zone, clear the Store The Zone In Active Directory check box, and click Next. The Zone Name page appears.
14.	In the Zone Name text box, type sub.contoso.com, and then click Next. The Zone File page appears.
15.	Click Next to accept the default selection, Create A New File With This File Name. The Master DNS Servers page appears.
16.	In the IP Address text box, type 192.168.0.2 (or the IP address currently assigned to Server02), click Add, and then click Next. The Completing The New Zone Wizard page appears.
17.	Click Finish. The sub.contoso.com zone now appears in the DNS console tree under the Forward Lookup Zones node.
18.	Right-click the sub.contoso.com node in the console tree (not the details pane), and then select Transfer From Master. Tip If you receive an error message, wait 10 seconds and try step 15 again.
19.	When the zone loads successfully, the node shows only three resource records: the SOA resource record for the zone and the NS resource records pointing to Server02 and Server01.