Root servers
| Line 1: | Line 1: | ||
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. | 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 nameserver|authoritative]] answers for the top level domain, you will be forwarded again, and repeat your query again. Once you arrive at the | + | Once given this address, you repeat your query to that server. If you are still not in the right cluster to provide [[authoritative nameserver|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 [[DNS record types|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: | For example, when you visited www.freebsdwiki.net, either your own nameserver or your ISP's nameserver had to first resolve the [[DNS record types|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: | ||
Revision as of 00:54, 21 May 2006
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 your DNS resolver asked a.root-servers.net (after finding its IP from your own root hint file) where to find www.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 .net part of your URL. And since it figured you would just come right back and pester it for directions to that NS record anyway, it volunteered the corresponding A record, which contained its actual IP address, without making you specifically ask 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 of the URL you wanted - so it told you that the NS named ns1.jrssystems.net knew all about freebsdwiki.net, and gave you the corresponding A record so you could go ask 66.154.114.98 about the final third level domain to your URL, the www .
Finally, on arriving at ns1.jrssystems.net, you had reached the server ultimately authoritative all the way down to the final level of subdomain in the URL you originally asked for - www.freebsdwiki.net. Since that's as far as you were trying to go, for the first time you were given an actual answer to your query instead of getting passed on to another nameserver. So now that your DNS resolver knew the host (aka A record) you were looking for could be found at 66.154.114.98, it handed the actual IP address to your web browser, which then requested this server for this web page, and here you are.
