Have you ever performed a 'whois' on a domain name to see what name servers are authoritative for it? Did you know that this information is not the information that is used when your domain name is actually resolved to an IP address? The authoritative name servers for a domain are actually stored in the Internet's DNS root servers. The data you receive from performing a whois on a domain is for convenience only, and may not always be accurate. In this article we will examine the roll of the DNS root servers, and the basics of domain resolution.

        First we need a little bit more background. Any time an application needs to find the IP address of a domain name (any time a network connection needs to be made when you have supplied the domain instead of the IP) it must resolve the domain to an IP address. The libraries and utilities that resolve domain names to IP addresses are called "resolvers." It is the resolvers job to request the IP address –but this is all it does. It is actually the DNS server you are using to resolve that does the heavy lifting.

         When you setup your Internet connection typically you setup the IP addresses of two or three name servers your resolvers (applications) will use to resolve domain names. This is usually done automatically if you obtain your IP address from a DHCP server. The administrator of the DHCP server typically configures it with the IP addresses of the local DNS servers. This information is then transferred to your computer when you obtain a lease. Alternately you might manually specify the IP addresses of two or more DNS servers for your applications to use when resolving domain names. It is these DNS servers your applications will use to obtain IP addresses from domain names, if the information in here is wrong the application may not get the expected connection. The resolver's job is to only make a request for an IP address from one of these DNS servers, the DNS server itself actually finds the IP address before returning it to the resolver. 

        The general flow for DNS resolution can be thought of in this order. This is highly simplified, but illustrates the point.

1. The resolver (application) asks the configured DNS server to return the IP address for a domain.
2. If the DNS server happens to have that domain and corresponding IP in it's cache, and the entry isn't old, it returns this information.
3. If the DNS server doesn't have any information regarding the domain (or the information it has is old) it must find it. It does this by contacting one of the Internet's root DNS servers.
4. The root DNS servers typically refer the DNS server you are using to another set of "root" servers. This is usually a gTLD (generic top level domain, ie. .net, .com, .org) or ccTLD (country code top level domain, ie. .us. uk. .ca) server.
5. The DNS server you are using receives information from this second stage of servers telling it where to go next. This process is repeated until the IP address is eventually returned.
6. The DNS server you are using stores this information in it's cache, and returns the results to your resolver –which returns it to your application –which then establishes an IP connection to the IP address returned.

        Now, you might be asking yourself: "When did the whois servers get queried." Well, the whois servers never got involved in the process at all. It is the Internet root DNS server system that actually refers the resolver to the correct location. 

        Let's pause for a moment to discuss the root servers. The root servers are 13 servers owned and operated by various different organizations, and are located around the globe. These servers do not store the IP address of the domain name you are trying to resolve. Their job is to refer the resolving DNS server to another high-level domain server group. This is typically the gTLD or ccTLD server group.
        To see a list of the 13 root servers visit www.root-servers.org. The next levels of servers (gTLD and ccTLD) are typically configured with the authoritative servers for a given domain.

        Now we can take a look at an illustration of how this works. We will be using the 'dig' utility to show the process. You can use just about any DNS utility to do this yourself if it allows you to query a specific server (if you are using Windows check out the nslookup utility from a DOS prompt). Dig let's us specify the server using the '@' option. The following command would ask 'ns.westhost.com' directly if it has information regarding 'mysite.com.'

dig mysite.com @ns.westhost.net

        We can use this syntax to connect to one of the root servers, and query it directly. We will follow the process step by step. As a note, the output listed here has been edited to only show the relevant portions. There is actually much more output. 

Command:

dig slashdot.org @f.root-servers.net

Output:

;; AUTHORITY SECTION:
org.                    172800  IN      NS      TLD4.ULTRADNS.org.
org.                    172800  IN      NS      TLD5.ULTRADNS.INFO.
org.                    172800  IN      NS      TLD6.ULTRADNS.CO.UK.
org.                    172800  IN      NS      TLD1.ULTRADNS.NET.
org.                    172800  IN      NS      TLD2.ULTRADNS.NET.
org.                    172800  IN      NS      TLD3.ULTRADNS.org.

Discussion:
       The command has queried one of the root DNS servers listed at root-servers.org. We have randomly selected a root server to query. All of the root servers should return the same results (and usually do). The output we are most interested in is the "AUTHORITY SECTION". This tells us that the server we just queried is not responsible for holding the IP address of the domain. The root servers simply told us that we are looking up a domain that ends in .org, and that we should query one of the six servers that have information regarding .org domains (gTLD root server group).

Command:

dig slashdot.org @TLD2.ULTRADNS.NET

Output:

;; AUTHORITY SECTION:
slashdot.org.           86400   IN      NS      ns3.vasoftware.com.
slashdot.org.           86400   IN      NS      ns2.vasoftware.com.
slashdot.org.           86400   IN      NS      ns2.osdn.com.
slashdot.org.           86400   IN      NS      ns1.vasoftware.com.
slashdot.org.           86400   IN      NS      ns1.osdn.com.

 Discussion:
      We have now queried one of the name servers responsible for storing information about domains ending in .org. The output shows us the authoritative servers for slashdot.org! That is right –the same information that could be retrieved from a whois lookup is also available using this method. These are the actual servers that resolving DNS servers will use to dig deeper (now you know where the utility "dig" gets it's name). The five servers listed in the output are all authoritative servers for slashdot.org (what is in the left column).
        Now that we know which servers are authoritative for slashdot.org we can query one of them directly. As a side note, you may notice that these lists contain several entries. This is for redundancy so that if one DNS server in the list stops functioning another can fulfill the request.
        There are occasional instances where a domain owner has changed the authoritative name servers recently. In these cases often the whois database updates before the root servers do. The information you receive from a whois lookup and the information from the root servers will not match. This usually resolves itself over the space of a few hours (pun not intended).

Command:

dig slashdot.org @ns2.osdn.com

Output:

;; ANSWER SECTION:
slashdot.org.           7200    IN      A       66.35.250.150

;; AUTHORITY SECTION:
slashdot.org.           7200    IN      NS      ns1.vasoftware.com.
slashdot.org.           7200    IN      NS      ns2.osdn.com.
slashdot.org.           7200    IN      NS      ns2.vasoftware.com.
slashdot.org.           7200    IN      NS      ns3.vasoftware.com.
slashdot.org.           7200    IN      NS      ns1.osdn.com.

Discussion:
         Here we finally receive the IP address for slashdot.org. This information in a normal lookup would be stored in the resolving DNS server's cache for 7200 seconds (this is called the time to live, or TTL). When that number expires in the DNS server's cache, and you request slashdot.org again, the whole process will be performed again.
           You may notice that the output also contains an authority section. This information is what the authoritative DNS server has configured as being authoritative for the domain (I know it seems odd, but it's important). In this case ns2.osdn.com has returned a list of all the DNS servers that should be configured as authoritative. Occasionally this list doesn't match the list returned from the root DNS servers. If this occurs the final DNS server you queried is said to be 'lame' –meaning that it is misconfigured. This could be a tip off to an administrator if a domain name is not resolving correctly. One caveat is that there could be nothing wrong with the domain at all. It could be thatt a lazy administrator hasn't updated a record. This is why it is called 'lame' instead of broken. It could still work, and it could still be accurate, but you cannot be 100% positive unless you happen to be the administrator that configured the server as lame (curses to you if you are).

       We have examined in a very general fashion how domain name lookups are performed, and the roll of the Internet's root DNS servers in resolving domains. At no time was a whois server queried, it was all done within the DNS system. Typical whois databases are meant to give us more information only. You can see that the DNS servers do not return much information. If there was a problem (a lame server for example) there is not a name or phone number we can contact listed in the DNS output. This is what the whois system is for –to allow others to find out who owns a domain so they can be contacted should the need arise.

        To find out more information about how the DNS system works check out DNS & BIND from O'Reilly.