Name resolution

For the sake of completeness, we will review the process of domain name resolution.

Resolvers (the client side software) is, on the whole, not particularly intelligent. As a result of this, the name server must be able to provide information for domains for which they are authorities, and the name server should also have the ability to search within the name space (all the domains from the root) for information about hosts for which they are not authoritative.

No single name server could possibly hold records for every domain on the Internet. In order to have a point to begin searching the name space, there are a number of root name servers. These servers fulfill the role of containing information about who the authorities for particular domains are. In much the same was that the authority for the "" domain can not answer queries about what the IP address for host is, but instead passed the query on to the authority for the domain, the root name servers contain information about who to forward the query to.

In effect, the root servers contain only a relatively small number of hosts for which they know the answers (relative that is, when compared to the number or hosts and domains on the Internet as a whole). let's go on a virtual travel trip. Been to Antarctica lately? Go to (and while we're there, head for ..... the webcam at

Perhaps your name server may have this domain in its local cache, but let's assume for now it doesn't. Since your name server has no knowledge of this domain (i.e. Your name server is non-authoritative for the domain) it will request information on who the authorities are for the 'au' domain.

To do this at the command line is simple with the dig utility (or nslookup if you don't have dig).


dig NS au.

This should return the names of the servers who hold information about the Australian domains:

au.        172511  IN      NS      NS.UU.NET.
au.        172511  IN      NS
au.        172511  IN      NS      BOX2.AUNIC.NET.
au.        172511  IN      NS      SEC1.APNIC.NET.
au.        172511  IN      NS      SEC3.APNIC.NET.
au.        172511  IN      NS      ADNS1.BERKELEY.EDU.
au.        172511  IN      NS      ADNS2.BERKELEY.EDU.

Now query the domain.

	dig NS

which should return:

;; ANSWER SECTION:    86400   IN      NS    86400   IN      NS    86400   IN      NS    86400   IN      NS    86400   IN      NS    86400   IN      NS    86400   IN      NS    86400   IN      NS    86400   IN      NS    86400   IN      NS

These are the name servers that hold information about the domains. You will notice that at least one of these hosts ( is repeated in both lists. To relate this back to the query issued by your name server on your resolvers behalf:

It (the name server) would have asked one of the root servers for the authoritative name servers for the 'au' domain. That received, it would then ask one of the authoritative name server for the '' domain.

Then again for the domain, which would have produced:

;; ANSWER SECTION:    84727   IN      NS    84727   IN      NS

Now that your name server knows whom to ask for information about, and the fact that this is the authoritative server for this domain, it can go ahead and ask it's question:

dig A

which should return:

;; ANSWER SECTION:         1556    IN      A

Notice that I can leave off the trailing full-stop here. In fact, I could have done that from the start.

Furthermore, in the previous dig commands, we were querying for the name server (NS) records. Now, if we were to query for its name server record, we would get nothing returned so instead, we query for the address (A) record for this host, and we get it.