DNS Stub Zones in Windows Server 2003

8/2/2019 DNS Stub Zones in Windows Server 2003

1/14

DNS Stub Zones in Windows

Server 2003

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 ofDNS 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 zonesfit into the overall picture.

Types of DNS Zones

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

Secondary zones, which store their zone information in a read-only text file on the nameserver.

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 (theprimary name serverfor the domain) and the other containing the standardsecondary 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 thenew host using DNS. To do this, the administrator would create a new A record on the primaryname 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

serverfor this zone.


2/14

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-onlyzone 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 introducingActive Directory Integrated

zones, which stored their zone information within Active Directory instead of text files. Theadvantages 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 asthey 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 (disjointednamespace), 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 inCompany A need access to resources on Company B's internal network. The usual way ofproviding 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 theirresource 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 nameservers 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 inCompany 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 resourcerecords 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 zoneon 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.


3/14

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 isalways 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. Also, while most

DNS servers can be configured to prevent zone transfers to secondary zones from occurring, stubzones 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 zonescan'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 theDNS 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 stubzone will then be automatically replicated to all other domain controllers on Company A'snetwork. Now when a client on Company A's network wants to connect to a resource onCompany 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.

How to Create a Stub Zone

Let's see how it works in practice. In my lab I have two forests set up, one for Company A

running Windows 2003 Server and named test2003.local, and the other for Company B runningWindows 2000 and named test2000.local. The domain controller for the root domain of

Company A is named SRV220 while the domain controllers for the root domain of Company Bare named SRV210, SRV211 and SRV212. Sally is an employee of Company A and her desktopcomputer is named DESK231, and she needs to access a share named CATALOG located on

SRV210 in Company B. To do this she clicks Start, selects Run, and types

\\srv210.test2000.local\catalog and the result is an error:

This is because her command issues a DNS query against her name server SRV220 which has no

information in its DNS database about test2000.local, the root domain of Company B:


4/14

To allow users in Company A to access resources in Company B, the administrator of CompanyA decides to create a stub zone for Company B's domain. To do this, right-click on ForwardLookup Zones in the figure above and select New Zone. This starts the New Zone Wizard:

Clicking Next brings up the Zone Type screen, and we'll choose Stub Zone here and select thecheckbox to create an Active Directory Integrated stub zone:


5/14

Click Next and the Active Directory Zone Replication Scope screen is displayed, which we'll

leave at its default setting for automatic replication of stub zone information to all domaincontrollers in the test2003.local domain.

Clicking Next displays the Zone Name screen, and here we type test2000.local as the name of

the stub zone since this is the name of the target domain on Company B's network:

Clicking Nextdisplays the Master DNS Servers screen, and we enter the IP address 172.16.11.210 for one of


6/14

the name servers on Company B's network:

Clicking Next and then Finish runs the wizard and creates the new stub zone, which here ishighlighted in the DNS console connected to SRV220 on Company A's network:

Note in the above figure that as expected the stub zone contains only an SOA record, an NS

record for each name server in the domain, and an A record for each name server in the domain.Now when Sally clicks Start, selects Run, and types \\srv210.test2000.local\catalog a window

opens up displaying the contents of the CATALOG share on SRV210 in the remote forest:


7/14

Stub zones are easy to create and can make name resolution between forests more efficient, but they

have other uses as well. For example, stub zones can enable name servers to perform recursion without

needing to query the Internet root name servers or internal corporate root servers, thus decreasing the

number of hops between name servers and making name resolution more efficient. Another use of stubzones is to keep delegated zone information up to date and prevent lame delegations from wrecking

name resolution within a forest, and that would make a good topic for a future article. Both of these are

good topics for future articles, so stay tuned for more on stub zones later.

Forwarders and Forwarding

When a name server is queried in DNS, the way it responds depends on the type of query issued,

which can be either iterative or recursive. In an iterative query, the client asks the name serverfor the best possible answer to its query. The name server checks its cache and the zones for

which it is authoritative and returns the best possible answer to the client, which could be either afull answer like "here is the IP address of the host you are looking for" or a partial answer like

"try this other name server instead, it might know the answer." In a recursive query, things worka little different for here the client demands either a full answer (the IP address of the target host)

or an error message like "sorry, name not found." In Windows DNS, client machines always

send recursive queries to name servers, and name servers usually send iterative queries to othername servers.

Sometimes this process isn't enough however. A simple example is a company that has ActiveDirectory deployed on its internal network and uses a private top-level domain like .local for its

forest. For example, say a company has a single Active Directory domain named test2003.local,

a domain controller (and DNS server) named SRV220 and has a dedicated connection to theInternet. A user named Bob goes to his desktop computer named DESK231, opens InternetExplorer, and tries to access Google (www.google.com). Here's what happens DNS-wise as far

as name resolution is concerned:

1. DESK231 sends a recursive query to SRV220 asking to resolve www.google.com into itsassociated IP address.


8/14

2. SRV220 looks in its DNS database and finds zone information only for the test2003.localdomain, realizes www.google.com is not part of that domain, decides it has no way ofknowing how to resolve www.google.com into an IP address, and what happens next

depends:

a. If, when you promoted your standalone server to the role of domain controllerusing dcpromo, your machine was disconnected from the Internet and there wereno other DNS servers on your network, then dcpromo creates a root zone (".") in

its DNS database that specifies itself as the root name serverfor all DNS name

resolution (that is, "the buck stops here"). In this case, SRV220 realizes it can'tanswer the query and returns a "name not found" error to the client and Bob can't

open the Google home page.

b. If however, when you promoted your server to a domain controller, your machinewas connected to the Internet, then Windows contacts the first available Internet

root name server and downloads a list of all Internet root name servers, which

becomes its list ofroot hints. In that case name resolution now continues as

follows:

3.

SRV220 sends an iterative query to the first available Internet root name server, whichresponds with the IP address of a name server authoritative for the .com top-level

domain.4. SRV220 sends a second iterative query to the name server authoritative for .com, and this

machine responds with the IP address of a name server authoritative for the google.com

domain.5. SRV220 sends a third iterative query to the name server authoritative for google.com,

and this machine responds with the IP address of the host named www.google.com.

6. SRV220 returns the IP address of www.google.com to DESK231 and Bob sees theGoogle home page appear in his browser.

Now that's a lot of steps, and if the company has a slow WAN link to the Internet then you're

using valuable bandwidth. A better approach than "going up to root" to resolve www.google.comwould be to configure a forwarder. Aforwarderis a name server that handles name queries that

can't be resolved by another name server. Let's see how the above scenario works when a

forwarder is configured on the internal name server SRV210:

1. DESK231 sends a recusrive query to SRV220 asking to resolve www.google.com into itsassociated IP address.

2. SRV220 looks in its DNS database and finds zone information only for the test2003.localdomain, realizes www.google.com is not part of that domain, decides it has no way of

knowing how to resolve www.google.com into an IP address, and checks its list of

forwarders to see if any forwarders have been configured for it.3. On the forwarders list it finds the IP address of the external name server hosted by the

company's Internet Service Provider, so it forwards the query to the ISP's name server to

handle.4. The ISP's name server goes up to root as needed (which can involve two or more

additional queries) to resolve www.google.com into its IP address and returns this

address to SRV220.5. SRV220 returns the address to Bob and he sees Google appear in his browser.


9/14

Note that this procedure takes about the same number of steps as before, but most of these steps

are performed offsite by the ISP's name server, so the amount of bandwidth used over theInternet connection is considerably less and the processing load on the internal name server

SRV220 is minimized as well. And these are good things from an administrator's perspective. Of

course, if the forwarder doesn't respond within the timeout configured, the server can either try

another forwarder (if configured) or use root hints (if available) or give up and return an error.

On Windows 2000, forwarders are configured using the General tab of the DNS server'sproperties sheet in the DNS console:

What's different in Windows Server 2003 is the concept ofconditional forwarding, which I'lllook at next.

What Conditional Forwarding Does

A conditional forwarder is one that handles name resolution only for a specific domain. For

example, you could configure your name server to forward any requests for hosts in the domain

google.com directly to a specific name server that is authoritative for the google.com domain.What this does is speed up the name resolution process by eliminating the need to go up to root

to find this authoritative server. In this case our previous example would now look like this:


10/14

1. DESK231 sends a recusrive query to SRV220 asking to resolve www.google.com into itsassociated IP address.

2. SRV220 looks in its DNS database and finds zone information only for the test2003.localdomain, realizes www.google.com is not part of that domain, decides it has no way of

knowing how to resolve www.google.com into an IP address, and checks its list of

forwarders to see if any forwarders have been configured for it.3. On the forwarders list it finds a conditional forwarder configured, which specifies the IPaddress of an authoritative name server for the google.com domain, so it forwards the

query to this name server to handle it.4. The google.com name server immediately resolves www.google.com into its IP address

without the need of going up to root and returns this address to SRV220.

5. SRV220 returns the address to Bob and Google quickly shows up in his browser,prompting Bob to say, "Hey, the network sure is fast today!"

Let's now see how to configure this in Windows Server 2003 DNS.

How to Configure Conditional Forwarding

First let's find a name server authoritative for the google.com domain. To do this we'll use theWHOIS lookup tool on the NetworkSolutions website at

http://www.networksolutions.com/en_US/whois/index.jhtml. Go to this page, type google.com

into the WHOIS search box, enter the code displayed (a feature that prevents mass lookups byautomated programs), and the following results are displayed:

google.com

Whois Server Version 1.

Domain names in the .com and .net domains can now be registered

with many different competing registrars. Go tohttp://www.internic.netfor detailed information.

Domain Name: GOOGLE.COMRegistrar: ALLDOMAINS.COM INC.

Whois Server: whois.alldomains.com

Referral URL:http://www.alldomains.com

Name Server: NS2.GOOGLE.COMName Server: NS1.GOOGLE.COM

Name Server: NS3.GOOGLE.COMName Server: NS4.GOOGLE.COMStatus: REGISTRAR-LOCK

Updated Date: 03-oct-2002

Creation Date: 15-sep-1997Expiration Date: 14-sep-2011

Let's find out the IP address of name server NS1.GOOGLE.COM using ping:
http://www.internic.net/http://www.internic.net/http://www.internic.net/http://www.alldomains.com/http://www.alldomains.com/http://www.alldomains.com/http://www.alldomains.com/http://www.internic.net/


11/14

Now that we have the IP address of one of the name servers authoritative for the google.com

domain, we can configure Windows Server 2003 DNS to conditionally forward all name queriesfor this domain to this name server.

To configure conditional forwarding, open the DNS console under Administrative Tools, right-click on the DNS server node, select properties to open the Properties sheet for the DNS server,

and select the Forwarding tab:


12/14

If you compare this to the previous figure for Windows 2000 DNS above, you'll see a few

differences. First, if you just want to configure a regular forwarder here, leave "All other DNSdomains" selected in the DNS domain listbox, enter the IP address of the forwarder (typically the

address of your ISP's name server) in the dotted box, and click Add. If you want to add aconditional forwarder however, do the following. First, click the New button and type the name

of the domain you want your name server to conditionally forward to:

Click OK and the new domain appears in the top listbox (make sure it is selected for the nextstep):


13/14

Now type the IP address of your conditional forwarder into the dotted box and click Add to add

it to the selected domain's forwarders list:

Click OK to apply the change and close the properties sheet and you're done. Now any namequeries for the google.com domain that are issued against the name server are forwarded directly

to the name server for the google.com domain to resolve.

Using Conditional Forwarding

When might you want to use conditional forwarding in the real world? I can think of several

situations where it might be useful:

To improve name resolution between two separate companies that need to provide theirusers with access to resources in the other company's intranet. This sort of situation iscommon in a merger situation or between supply-chain partners. Just set up DNS servers

in each company to forward name requests for resources in the other company's network

directly to the IP addresses of name servers in the other company and you're done. Of

course, this can also be done using stub zones as I discussed in my previous articleDNSStub Zones in Windows Server 2003and I'll compare the two approaches in a moment.
http://www.windowsnetworking.com/articles_tutorials/DNS_Stub_Zones.htmlhttp://www.windowsnetworking.com/articles_tutorials/DNS_Stub_Zones.htmlhttp://www.windowsnetworking.com/articles_tutorials/DNS_Stub_Zones.htmlhttp://www.windowsnetworking.com/articles_tutorials/DNS_Stub_Zones.htmlhttp://www.windowsnetworking.com/articles_tutorials/DNS_Stub_Zones.htmlhttp://www.windowsnetworking.com/articles_tutorials/DNS_Stub_Zones.html


14/14

To improve name resolution within an Active Directory implementation that has adisjointed namespace (separate forests or multiple domain trees) or a deep hierarchy ofsubdomains. In this kind of situation you can set up conditional forwarding so users in

one domain can avoid having to go all the way to root to find resources in a separate

forest, another domain tree, or way down the domain hierarchy in a tree. Again, stub

zones could also be used for this purpose if desired. And then there's using it simply to forward name queries for specific Internet sites like

google.com as in the example above, but that example was meant only to be illustrative

of the procedure for configuring conditional forwarding on your name server--my

company has no plans on merging with Google anytime soon.

It's a subdomain created to register Microsoft specific services. SinceMicrosoft has used standard technologies that others use such as DNSand LDAP, this allows a computer to query DNS for a Microsoft specific

implementation of the service.

For example, if you wanted to log on to a Windowsdomain, you needto contact a Windows domain controller. Domain controllers use LDAP

to query AD for the account during logging in. This is how Windowsclients ensure when they query for LDAP servers in the domain lookingfor adomain controller, they actually get a Windows DC, not someLinux LDAP server. The Linux LDAP server would be listed in theregular domain, not this special subdomain.
http://www.computing.net/answers/windows-2003/msdcs-what-is-it/4043.htmlhttp://www.computing.net/answers/windows-2003/msdcs-what-is-it/4043.htmlhttp://www.computing.net/answers/windows-2003/msdcs-what-is-it/4043.htmlhttp://www.computing.net/answers/windows-2003/msdcs-what-is-it/4043.htmlhttp://www.computing.net/answers/windows-2003/msdcs-what-is-it/4043.htmlhttp://www.computing.net/answers/windows-2003/msdcs-what-is-it/4043.htmlhttp://www.computing.net/answers/windows-2003/msdcs-what-is-it/4043.htmlhttp://www.computing.net/answers/windows-2003/msdcs-what-is-it/4043.html

DNS Stub Zones in Windows Server 2003

Documents

Transcript of DNS Stub Zones in Windows Server 2003