DNS [Domain Naming System]

The basic concept of DNS name resolution is fairly simple & crispy. Every Web site is assigned a unique IP address. In order to access a website, a client needs to know what the site’s IP address is. Of course users don't usually enter an IP address into their Web browser, but rather enter the site's domain name instead. In order to access the requested website, the Web browser must be able to convert the site's domain name into the corresponding IP address. This is where DNS comes into play. The client computer is configured with the address of a preferred DNS server. The requested URL is forwarded to the DNS server, and the DNS server returns the IP address for the requested website. The client is then able to access the requested site.

As you can see, the name resolution process is pretty simple. However, there are countless websites in the world, and new sites are being created every day. It is impossible for your DNS server to know the IP address of every single website. When a DNS server does not know the address for a requested site, it uses one of two methods to determine the site's IP address.

The preferred name resolution method is called recursion. Generally speaking, recursion refers to the process of having the DNS server itself to make queries to other DNS servers on behalf of the client who made the original request. In essence, the DNS server becomes a DNS client.


Root Hints

If the DNS server does not know the address of the requested site, then it will forward the request to another DNS server. In order to do so, the DNS server must know of the IP address of another DNS server that it can forward the request to. This is the job of root hints. Root hints provided a list of IP addresses of DNS servers that are considered to be authoritative at the root level of the DNS hierarchy.

The good news is that root hints are preconfigured on Windows Server 2003 DNS servers. The root hints are stored in a file named CACHE.DNS that is located in the \Windows\System32\Dns folder. If you would like to see what the root hints file looks like, you can open it in Notepad. As you can see in Figure A, the root hints file is really nothing more than just a text file that pairs root DNS servers with their IP addresses.

Root Hints

The root hints file matches root level DNS servers with their IP addresses

Now that I have talked about what the root hints are and what they do, let’s take a look at the recursion process in action. The diagram shown in Figure B illustrates the example that I am about to walk you through.

The process begins when the user enters a URL into their Web browser. For the purpose of this example, let’s assume that the user has entered www.spiceup.net.in as the URL. Upon doing so, the request to resolve the spiceup.net.in domain into an IP address is passed to the workstation’s preferred DNS server. Often times the preferred DNS server will have already cached the requested record, but for the sake of this example, let’s assume that the preferred DNS server has no information related to spiceup.net.in.

The DNS server begins acting as a DNS client and launches a series or iterative queries against other DNS servers. I will discuss the difference between iterative and recursive queries later on.

At any rate, the workstation’s preferred DNS server doesn’t know the IP address of the www.spiceup.net.in Web site, and it doesn’t know the IP address of a DNS server that is authoritative for the spiceup.net.in domain (and would therefore know the IP address of the www.spiceup.net.in Web site). What the DNS server does know is the IP address to a root level DNS server (thanks to the root hints file). Therefore, the preferred DNS server forwards the request to the root DNS server.

The root DNS server doesn’t have a clue as to the IP address of the www.spiceup.net.in Web server.What it does know is the IP address of a DNS server that is responsible for the .in domain. The root DNS server returns the IP address of the DNS server responsible for the .in domain to the preferred DNS server. The preferred DNS server then sends the client’s request to the .in DNS server. The .in DNS server doesn’t know the IP address of the www.spiceup.net.in Web site, but it does know the IP address that is responsible for the .net.in domain. The root DNS server returns the IP address of the DNS server responsible for the .net.in domain to the preferred DNS server. The preferred DNS server then sends the client’s request to the .net.in DNS server. The .net.in DNS server doesn’t know the IP address of the www.spiceup.net.in Web site, but it does know the IP address of the DNS server that is authoritative for the spiceup.net.in domain. The .net.in domain server returns the IP address of the DNS server that is authoritative for the spiceup.net.in domain. The client’s preferred DNS server then sends the request to the spiceup.net.in DNS server, which in turn returns the IP address for the requested Web site. This address is then returned to the client who requested it.

There are two things worth noting in this example. First, as I explained earlier, the client only made a single DNS query. It was completely unaware of the DNS server’s Iterative queries on its behalf. Second, the DNS server that is authoritative for the spiceup.net.in domain would not necessarily be owned by SpiceUp. Typically, this DNS server would be owned by a Web hosting company and would be authoritative for any sites hosted by the company. That’s why the preferred DNS server can’t skip a step and just give the client the address for the DNS server that is authoritative for the domain; at least not in this case.

If a DNS server is configured to not support recursive queries, then clients will perform iterative queries by default.

With a recursive name query , the DNS client requires that the DNS server respond to the client with either the requested resource record or an error message stating that the record or domain name does not exist. The DNS server cannot just refer the DNS client to a different DNS server.

Thus, if a DNS server does not have the requested information when it receives a recursive query, it queries other servers until it gets the information, or until the name query fails.

Recursive name queries are generally made by a DNS client to a DNS server, or by a DNS server that is configured to pass unresolved name queries to another DNS server, in the case of a DNS server configured to use a forwarder.

An iterative name query is one in which a DNS client allows the DNS server to return the best answer it can give based on its cache or zone data. If the queried DNS server does not have an exact match for the queried name, the best possible information it can return is a referral (that is, a pointer to a DNS server authoritative for a lower level of the domain namespace). The DNS client can then query the DNS server for which it obtained a referral. It continues this process until it locates a DNS server that is authoritative for the queried name, or until an error or time-out condition is met.

If you are interested in obtaining the best performance, then you should configure your DNS server to allow recursive queries. The reason is because if clients are forced to use iterative queries, then they could potentially issue three or four queries to the DNS server for every name resolution request. The DNS server will have to perform all these queries whether recursive or iterative queries are being used, but when recursion is used, most of the name resolution requests are handled by your DNS server and are kept off of your network. This reduces the amount of traffic flowing across the network, thereby improving performance.

In this article, I have explained how recursive DNS queries work. Most DNS servers support both recursive and iterative queries from clients. Configuring your DNS server to support recursive queries will generally provide better performance because doing so will reduce the number of queries that network clients have to make.

Leave your comment below