When to Use Stub Zones in .NET

Drawing QR Code in .NET When to Use Stub Zones

Stub zones are most frequently used to keep track of the name servers 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 added to the parent zone manually. 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 fol lowing example, illustrated in Figure 5-34.

5-67

*new Primary zone: microsoft.com Name Server (NS) updates original Secondary server widgets.microsoft.com

Stub zone: widgets.microsoft.com original NS records: 192.168.2.1, 192.168.2.2 other NS Records: (added later)

original Primary server widgets.microsoft.com 192.168.2.1 Secondary server widgets.microsoft.com 192.168.2.2 *new

Figure 5-34

Expect to be tested on stub zones on the 70-291 exam. First and foremost, you need to be able to recognize scenarios in which deploying a stub zone is appropriate.

A DNS server 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

5-68

5

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 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 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 authoritative for the parent zone learns about the new name servers authoritative for the widgets.microsoft.com child zone and is able to perform recursion to all of the child zone s authoritative DNS servers.

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 5-35 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 dif ferent 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 authoritative for the appropriate domain (mgmt.ldn.microsoft.com) receives the query. In the second case, the DNS server 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 authoritative for ns.mgmt.ldn.microsoft.com, and it sends a recursive query directly to the authoritative server.