On the average Active Directory based network, DNS is one of
the most heavily used services. Any time that a host on your network wants to
contact another host on your network, query the Active Directory, access a Web
page, or send an E-mail message, the request must first pass through a DNS
server. Being that the DNS services are so heavily used and are such a critical
networking component, you might be surprised to learn that they are extremely
inefficient.

Sure, DNS offers a huge improvement over the WINS service
that was previously used by Windows NT to perform some of the name resolution
tasks that I mentioned above, but DNS still offers relatively poor performance
because of the number of steps that it uses to resolve queries. However, there
is a new feature in Windows Server 2003 called DNS conditional forwarding that
you can use to enhance your DNS server’s performance. In this article, I will
show you how conditional forwarding works and how you can use it in your own
network.

Why is DNS so slow?

Before you can really understand or appreciate conditional
forwarding, you need to understand what it is that makes DNS so slow and
inefficient. Throughout this article, I will be discussing various types of DNS
implementations. To demonstrate how these various implementations work, let’s
assume that you have a small, Windows Server 2003 network. This network has a
single domain controller named DC1 and that the domain controller doubles as a
DNS server. The network also has one Windows XP workstation (I told you it was
a small network), which we will call XP1. I realize that this example is
absolutely ridiculous when compared against an enterprise class network, but
the simplicity of my fictitious network will help to make the various
explanations easier to follow.

OK, so let’s go back to my original question of what makes
DNS so slow? Let’s assume for this example, that DC1 is running an out of the
box configuration, butï¿? the server was connected to the Internet prior to being
promoted to a domain controller / DNS server. Now, let’s say that a user
working off of XP1 opens Internet Explorer and enters http://www.techrepublic.com. Here’s
what happens.

  1. XP1 sends an iterative query to DC1 asking it to resolve techrepublic.com
    into its corresponding IP address.
  2. DC1 checks its cache of recently queried domain names and determines
    that techrepublic.com does not exist within the cache.
  3. DC1 opens its DNS database and finds zone information only for the
    local, Active Directory domain. Since techrepublic.com is not a part of the
    local domain, the DNS server has no way of resolving the query.
  4. Since DC1 was connected to the Internet prior to being promoted to a
    domain controller / DNS server, DC1 contacts an Internet based root name server
    and downloads a list of all existing Internet based root name servers. This
    becomes DC1’s list of root hints.
  5. DC1 sends a recursive query to the first root name server on the root
    hint list, asking for the IP address of the DNS server that is authoritative
    over the .COM domain.
  6. Once DC1 receives the response to this query, it sends a recursive query
    to the DNS server that is authoritative for the .COM domain, asking the server
    for the IP address corresponding to the DNS server that is authoritative for
    the techrepublic.com domain.
  7. DC1 now sends yet another recursive query. This time, it sends the query
    to the authoritative name server for techrepublic.com. The query returns the IP
    address associated with the techrepublic.com domain.
  8. DC1 receives the IP address and passes it to XP1.
  9. XP1 then accesses the address and the user sees the TechRepublic Web
    site displayed in Internet Explorer.

As you see, there are four separate DNS queries that have to
happen before our user can access a Web site. That’s a lot of overhead,
especially when you consider that everything that I just described has to
happen each time anybody in the organization tries to access a Web site.

DNS Forwarding

As you saw in the previous section, since the DNS server
didn’t know anything about the techrepublic.com domain, it had to initiate a
series of queries, all the way up to the root DNS level. One way that you can
reduce overhead though and make DNS a little more efficient though is to use a
technique called DNS forwarding (This technique also works with Windows 2000
Server).

The idea behind DNS forwarding is that when Windows installs
the DNS services, it makes the DNS services authoritative over your local
domains, but that’s it. If your server was connected to the Internet at the
time that the server was promoted to a domain controller / DNS server, then the
DNS server has knowledge that the Internet exists, but the DNS server was never
really intended to handle a large stream of Internet related queries.

The other thing that you need to understand in order to
understand DNS forwarding is that in most cases, your company’s network is not
directly connected to an Internet backbone. Your company gets Internet access
from an Internet Service provider. At the time that your company signed up with
your Internet service provider, they probably assigned you some IP addresses,
but they also gave you a list of IP addresses that could be used for things
like SMTP, POP3, and DNS. Your ISP has their own DNS server that is
specifically configured to handle Internet related queries. So why not let your
ISP deal with DNS queries instead of burdening your own network with them?

If your network is Active Directory based (and our example
network is), then you don’t have this luxury because Active Directory is
totally dependant on the DNS services. Any machine that is a part of the Active
Directory (including workstations) must be pointed to a DNS server that
contains the zone information specific to your network. This is where
forwarding comes into play. Forwarding is a technique by which you can tell
your DNS server that if queries come in that do not pertain to local domains
then those queries should be resolved by the ISP’s DNS server instead. This
greatly simplifies the name resolution process from your network’s point of
view. Here is what happens when the user at XP1 enters www.techrepublic.com
into Internet Explorer:

  1. XP1 sends an iterative query to DC1 asking it to resolve
    techrepublic.com
  2. DC1 checks its DNS cache and determines that techrepublic.com
    is not currently cached
  3. DC1 opens the DNS database and determines that it only
    contains information for the local domains, and that techrepublic.com is
    not a local domain.
  4. Since DC1 has no way of resolving techrepublic.com, it
    checks its list of forwarders for a forwarding address.
  5. Since the list of forwarders contains the IP address of
    your ISP’s DNS server, DC1 forwards the query to the ISP’s DNS server.
  6. The ISP’s DNS server resolves techrepublic.com into its
    corresponding IP address, and sends the result back to DC1.
  7. DC1 passes the resolved IP address back to XP1
  8. XP1 then goes to the specified address and Internet
    Explorer displays the TechRepublic Web site.

This process looks a lot simpler than the process that I
showed you earlier, but don’t let it fool you. In the first example that I
showed you, your DNS server had to make a root level query, followed by a few
additional queries.

In the second example, your DNS server passes the unresolved
query to your ISP’s DNS server and it resolves the query. The query isn’t
resolved by magic though. The ISP’s DNS server works exactly the same way that
your DNS server does. If your ISP’s DNS server doesn’t have knowledge of the
site that’s being queried, then it will have to perform multiple queries
starting at the root, just like your server would have.

If your ISP’s DNS server is forced to make a root level
query, then there are actually more steps involved in DNS forwarding then if
your DNS server had just resolved the query on its own. So why on earth would
you want to use DNS forwarding if it is potentially less efficient than just
allowing your DNS server to make the necessary queries on its own?

There are a couple of reasons why forwarding is preferred.
First, forwarding frees up your system resources. Using four different queries
to resolve a single address consumes a lot of processor time and bandwidth. If
you forward these requests to your ISP, you can use their CPU and bandwidth
resources rather than your own.

A second reason why forwarding is preferred is that even
though forwarding involves more steps than resolving queries yourself,
forwarding is often much faster. One reason why forwarding is often faster is
because there is a good chance that your ISP will have the resolved address cached
(remember, your company isn’t the only one making queries through your ISP’s
DNS). More importantly though, your ISP has a whole lot more bandwidth than you
do. Your ISP can probably make all of the necessary queries in less time than
it would take your DNS server to make even the first query.

As you can see, your network will usually resolve DNS
queries more quickly if you use DNS forwarding than if you do not. To implement
DNS forwarding, open the DNS console on your DNS server. When the console opens,
right click on your server and select the Properties command from the resulting
shortcut menu. When the DNS server’s properties sheet appears, select the
Forwarders tab. Now, enter the IP address corresponding to your ISP’s DNS
server into the place provided and click the Add button, followed by OK.

Conditional forwarding

So now that you have some background in how DNS works and in
DNS forwarding, let’s talk about conditional forwarding. Conditional forwarding
is designed to get queries to their destination in a fraction of the time. The
process works by associating a domain name with the IP address of the name
server that is authoritative for the domain.

This means that if your DNS server is unable to resolve the
IP address for a particular domain, the query would be automatically sent
directly to the DNS server that is authoritative for that domain, and the name
resolution would be returned instantly.

Here is exactly what would happen if you were to create a
conditional forwarding for techrepublic.com:

  1. The user at XP1 enters www.techrepublic.com into Internet
    Explorer.
  2. XP1 sends a DNS query to DC1
  3. DC1 checks the DNS cache to see if there is a cached entry
    for techrepublic.com
  4. if no cached entry is found, DC1 searches the DNS database
    for information related to the techrepublic.com domain.
  5. Since DC1 has no knowledge of the techrepublic.com domain,
    DC1 checks its list of forwarders to see if there are any conditional
    forwarders for techrepublic.com
  6. The forwarders list supplies the IP address of the DNS
    server that is authoritative for techrepublic.com
  7. The query is sent to the techrepublic.com DNS server,
    where the query is resolved.
  8. The remote DNS server passes the resolved IP address to
    DC1, which passes the IP address to XP1.
  9. The user is able to access the techrepublic.com Web site

OK, so let’s assume that you wanted to create a conditional
forwarder that pointed to techrepublic.com. To do so, you would have to go to http://www.networksolutions.com/en_US/whois/index.jhtml
and do a who is search on techrepublic.com. When you do, the following
information is returned:

Registrant:
 CNET Networks, Inc (DOM-311974)
 235 Second Street San Francisco CA 94105 US
 
 Domain Name: techrepublic.com
 
 Registrar Name: Alldomains.com
 Registrar Whois: whois.alldomains.com
 Registrar Homepage: http://www.alldomains.com
 
 Administrative Contact:
 Host Master (NIC-1500677) CNET Networks, Inc
 235 Second Street San Francisco CA 94105 US
 hostmaster@cnet.com +1.4153442000 Fax- +1.4153442000
 Technical Contact, Zone Contact:
 Host Master (NIC-1500677) CNET Networks, Inc
 235 Second Street San Francisco CA 94105 US
 hostmaster@cnet.com +1.4153442000 Fax- +1.4153442000
 
 Created on..............: 1998-Nov-20.
 Expires on..............: 2013-Nov-19.
 Record last updated on..: 2004-Jul-22 13:09:25.
 
 Domain servers in listed order:
 
 NS.CNET.COM 216.239.126.10
 NS2.CNET.COM 206.16.0.71
 NS3.CNET.COM 216.239.120.69

What you are interested in is the authoritative DNS server
for techrepublic.com The authoritative DNS server is usually the first one in
the Domain Servers In Listed Order Section. In this case, it’s NS.CNET.COM,
216.239.126.10. In this case we got lucky because we were provided with the DNS
server’s IP address and fully qualified domain name. Sometimes though, only the
fully qualified domain name is provided and you will have to ping the DNS
server in order to determine its IP address.

Now that you know the authoritative DNS server’s IP address,
go back to the Forwarders tab of the DNS server’s properties sheet (This is the
same tab that you used to set up a normal forwarder). This time instead of
directly entering an IP address, click the New button. When prompted to enter a
DNS domain, enter techrepublic.com and click OK. Techrepublic.com will now
appear just beneath the All Other DNS Domains entry in the list of forwarders.
At this point, select the techrepublic.com entry and enter the DNS server’s IP
address into the space provided and click Add, followed by OK. You have now
created a conditional forwarder.

Words of caution

Now that I have shown you how to create conditional
forwarders, and you know just how much time conditional forwarders can save, I
feel obligated to give you a few words of caution. Right about now, you might
be thinking that it would be a good idea to check the logs on your router to
determine the 50 Web sites that are visited the most often and then create
conditional forwarders for those sites. This is actually a really bad idea for
a couple of reasons.

First, having more than a handful of conditional forwarders
can make the DNS query process run more slowly than if conditional forwarders
were not used at all, because every outbound query has to be compared against
every item on the list of forwarders.

Another reason why big lists of conditional forwarders are a
bad idea is because DNS servers sometimes change, as do IP addresses. For
example, if I were to become dissatisfied with my ISP and moved my Web site to
a different ISP for hosting, a completely different DNS server would become
authoritative for my domain. If someone had a conditional forwarder set up to
point to the previously authoritative DNS server, the entry would no longer
point to the correct location. Worse yet, if the DNS server’s IP address were
to change, a network with a conditional forwarder pointing to that DNS server
would no longer be able to access the domain in question.

Just because there are some serious issues to consider in
regard to conditional forwarders doesn’t mean that conditional forwarding doesn’t
have its place though. There’s certainly no harm in creating conditional
forwarders for a couple of Web sites (assuming that the DNS doesn’t change).
For example, you might create a conditional forwarder that will help the
Windows update service to work more efficiently. You might create another one
that points to your anti virus company since your anti virus software regularly
updates itself. Finally, you might create a conditional entry for a search
engine such as Google. That’s about as far as I would recommend taking
conditional forwarding for Web sites though.

Conditional forwarding is much more appropriate in
situations in which you have a working relationship with another company and
access their network from your network on a regular basis. For example, if a
domain in your forest had an external trust relationship to a domain in a
remote forest, then it might be appropriate to create a conditional forwarding
entry for that domain (assuming that it is heavily used). Likewise, if you
regularly access a database on a supplier’s server, then this would be another
good time to use a conditional forwarding entry.