Root servers

The root servers are the top tier of nameservers which contain the necessary information to resolve each of the top level domains of the internet. There are currently several clusters of root servers. Within each cluster, the member servers are spread out geographically both to minimize latency and to maximize fault tolerance for the internet as a whole. The separate clusters service separate top level domains; if you initially query a root server which is not a member of the proper cluster it will give you the IP address of a server in the correct cluster.

Once given this address, you repeat your query to that server. If you are still not in the right cluster to provide authoritative answers for the top level domain, you will be forwarded again, and repeat your query again. Once you arrive at the authoritative nameserver for your top level domain, you repeat your query to it, and it will point you to the authoritative nameserver for the second level domain. This process can continue once or more for every subdomain level of the URL you wish to resolve.

For example, when you visited www.freebsdwiki.net, either your own nameserver or your ISP's nameserver had to first resolve the A record to an IP address, beginning from the root servers and working its way downward, repeating the same query to progressively lower-hierarchy servers until it got its final answer. That process, were you to repeat it on the command line with the DNS tool dig, would have looked much like this:

workstation# dig @a.root-servers.net www.freebsdwiki.net
        ;; ->>HEADER<<- QUERY: 1, status: NOERROR, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14
        ;; AUTHORITY SECTION:   NS      A.GTLD-SERVERS.net.
        ;; ADDITIONAL SECTION:          A.GTLD-SERVERS.net.     172800  IN      A       192.5.6.30

workstation# dig @a.gtld-servers.net www.freebsdwiki.net
        ;; ->>HEADER<<- QUERY: 1, status: NOERROR, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
        ;; AUTHORITY SECTION:   NS      ns1.jrssystems.net.
        ;; ADDITIONAL SECTION:          ns1.jrssystems.net.     172800  IN      A       66.154.114.98

workstation# dig @ns1.jrssystems.net www.freebsdwiki.net
        ;; ->>HEADER<<- QUERY: 1, status: NOERROR, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
        ;; ANSWER SECTION:              www.freebsdwiki.net.        300     IN      A       66.154.114.98

Basically, it went like this: first you asked a.root-servers.net (after finding its IP from your own root hint file) where to find freebsdwiki.net. It didn't know the answer, but it did know you should be asking one of the gtld-servers about the .net TLD - so it told you that it knew an NS (nameserver record) for the gtld-servers. And since it figured you would just come right back and pester it for directions to that NS record, it went ahead and gave you the corresponding IN A (internet-class A record), which contained its actual IP address, before you specifically asked for it.

So then you asked a.gtld-servers.net, but it didn't know the answer either. However, it did know the authoritative nameserver for the second level domain freebsdwiki.net - so it told you to go ask the NS ns1.jrssystems.net, and gave you its A record, which said to find it at 66.154.114.98.

Finally on arriving at ns1.jrssystems.net, you had reached the server ultimately authoritative all the way down to the third level domain - www.freebsdwiki.net. Since that's as far as you were trying to go, for the first time you were given an actual answer, that the host (aka A record</a>) you were looking for could be found at 66.154.114.98. At that point, your DNS resolver handed that final IP address over to your web browser, which then requested the server at that IP address for this web page, and here you are.