Conditional forwarding is a new feature of DNS in Windows Server

2003 that can be used to speed up name resolution in certain

scenarios. They can also be used to help companies resolve each
other's namespace in a situation where companies collaborate a
merger is underway. This article will look in detail at how conditional
forwarding works, how to configure it, and when you might use it. But
first, let's briefly review the concepts of forwarding and forwarders in
traditional DNS, starting with different types of name queries.

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 server for 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 a full 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 work a 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 other name servers.

Sometimes this process isn't enough however. A simple example is a

company that has Active Directory 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 the Internet. A user named Bob
goes to his desktop computer named DESK231, opens Internet
Explorer, 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 its associated IP address.
2. SRV220 looks in its DNS database and finds zone information
only for the test2003.local domain, 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 what happens
next depends:
a. If, when you promoted your standalone server to the role
of domain controller using dcpromo, your machine was
disconnected from the Internet and there were no other
 DNS servers on your network, then dcpromo creates a root
zone (".") in its DNS database that specifies itself as the
root name server for all DNS name resolution (that is, "the
buck stops here"). In this case, SRV220 realizes it can't
answer 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 machine was 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 of root hints. In that case
name resolution now continues as follows:
3. SRV220 sends an iterative query to the first available Internet
root name server, which responds 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 the Google 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.com would be to
configure a forwarder. A forwarder is 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 its associated IP address.
2. SRV220 looks in its DNS database and finds zone information
only for the test2003.local domain, 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.

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 the Internet
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's properties sheet in the DNS console:

What's different in Windows Server 2003 is the concept of conditional

forwarding, which I'll look 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:

1. DESK231 sends a recusrive query to SRV220 asking to resolve

www.google.com into its associated IP address.
2. SRV220 looks in its DNS database and finds zone information
only for the test2003.local domain, 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 IP address 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 the WHOIS 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 by automated
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 to http://www.internic.net
for detailed information.

Domain Name: GOOGLE.COM

Registrar: ALLDOMAINS.COM INC.
Whois Server: whois.alldomains.com
Referral URL: http://www.alldomains.com
Name Server: NS2.GOOGLE.COM
Name Server: NS1.GOOGLE.COM
Name Server: NS3.GOOGLE.COM
Name Server: NS4.GOOGLE.COM
Status: REGISTRAR-LOCK
Updated Date: 03-oct-2002
Creation Date: 15-sep-1997
Expiration Date: 14-sep-2011

Let's find out the IP address of name server NS1.GOOGLE.COM using

ping:

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 queries for 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:
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 DNS domains" 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 a conditional 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 next step):
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 name queries 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 their users with access to resources in the
other company's intranet. This sort of situation is common 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 article DNS Stub Zones in Windows
Server 2003 and I'll compare the two approaches in a moment.
• To improve name resolution within an Active Directory
implementation that has a disjointed namespace (separate
forests or multiple domain trees) or a deep hierarchy of
subdomains. 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.

Summary