Root servers
| Line 3: | Line 3: | ||
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. | 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, | + | 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, by starting from the root servers and working its way downward. At each step, it had to ask a progressively lower-hierarchy server the same question: where is '''www.freebsdwiki.net'''? Finally, the buck was passed all the way down to the bottom, and it got its final answer. |
| + | |||
| + | That process can be repeated on the command line with the DNS tool [[dig]], and simplified a little, it looks a lot like this: | ||
workstation# '''dig @a.root-servers.net www.freebsdwiki.<font color="blue">net</font>''' | workstation# '''dig @a.root-servers.net www.freebsdwiki.<font color="blue">net</font>''' | ||
| Line 9: | Line 11: | ||
;; AUTHORITY SECTION: <font color="blue">NS A.GTLD-SERVERS.net.</font> | ;; AUTHORITY SECTION: <font color="blue">NS A.GTLD-SERVERS.net.</font> | ||
;; ADDITIONAL SECTION: <font color="blue">A.GTLD-SERVERS.net.</font> 172800 <font color="blue">IN A 192.5.6.30</font> | ;; ADDITIONAL SECTION: <font color="blue">A.GTLD-SERVERS.net.</font> 172800 <font color="blue">IN A 192.5.6.30</font> | ||
| − | + | ||
| + | |||
| + | First, we ask '''a.root-servers.net''' (which we found in the root hint file) where to find '''www.freebsdwiki.net'''. It didn't know the <font color="red">answer</font>, but it did know you should be asking one of the <font color="blue">gtld-servers</font> about the .net TLD - so it told you that it knew an <font color="blue">NS</font> (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 <font color="blue">A record</font>, which contained its actual <font color="blue">IP address</font>, without making you specifically ask for it. | ||
| + | |||
workstation# '''dig @a.gtld-servers.net www.<font color="blue">freebsdwiki</font>.<font color="green">net</font>''' | workstation# '''dig @a.gtld-servers.net www.<font color="blue">freebsdwiki</font>.<font color="green">net</font>''' | ||
;; ->>HEADER<<- QUERY: 1, status: NOERROR, <font color="red">'''ANSWER: 0'''</font>, AUTHORITY: 2, ADDITIONAL: 2 | ;; ->>HEADER<<- QUERY: 1, status: NOERROR, <font color="red">'''ANSWER: 0'''</font>, AUTHORITY: 2, ADDITIONAL: 2 | ||
| Line 15: | Line 20: | ||
;; ADDITIONAL SECTION: <font color="blue">ns1.jrssystems.net.</font> 172800 <font color="blue">IN A 66.154.114.98</font> | ;; ADDITIONAL SECTION: <font color="blue">ns1.jrssystems.net.</font> 172800 <font color="blue">IN A 66.154.114.98</font> | ||
| + | Following directions, next we ask <font color="blue">a.gtld-servers.net</font> - but it doesn't know the <font color="red">answer</font> either. However, it does know that the authoritative nameserver (<font color="blue">NS</font>) for '''freebsdwiki.net''' - the ''second'' level domain of the URL you wanted - is ns1.jrssystems.net. And just like a.root-servers.net, it gave you the corresponding <font color="blue">A record</font> before you could even ask. Next step: <font color="blue">66.154.114.98</font>. | ||
| + | |||
workstation# '''dig @ns1.jrssystems.net <font color="blue">www</font>.<font color="green">freebsdwiki.net</font>''' | workstation# '''dig @ns1.jrssystems.net <font color="blue">www</font>.<font color="green">freebsdwiki.net</font>''' | ||
;; ->>HEADER<<- QUERY: 1, status: NOERROR, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 | ;; ->>HEADER<<- QUERY: 1, status: NOERROR, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 | ||
<font color="green">''';; ANSWER SECTION: www.freebsdwiki.net. 300 IN A 66.154.114.98'''</font> | <font color="green">''';; ANSWER SECTION: www.freebsdwiki.net. 300 IN A 66.154.114.98'''</font> | ||
| − | + | Finally, we ask <font color="blue">ns1.jrssystems.net</font> for the last piece of the puzzle - '''www'''.freebsdwiki.net. Since <font color="blue">ns1.jrssystems.net</font> is authoritative for both the third (www) and second (freebsdwiki) subdomains of the .net top level domain, we are given the final <font color="green">answer</font> to our query, instead of being handed off to another nameserver. And now that the DNS resolver has the right <font color="green">A record</font> for the URL we wanted, it extracted <font color="green">66.154.114.98</font> from it, handed that to your web browser, which then fetched the web page, and here we are. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
[[Category:FreeBSD Terminology]] | [[Category:FreeBSD Terminology]] | ||
Revision as of 02:12, 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, by starting from the root servers and working its way downward. At each step, it had to ask a progressively lower-hierarchy server the same question: where is www.freebsdwiki.net? Finally, the buck was passed all the way down to the bottom, and it got its final answer.
That process can be repeated on the command line with the DNS tool dig, and simplified a little, it looks a lot 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
First, we ask a.root-servers.net (which we found in the 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.
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
Following directions, next we ask a.gtld-servers.net - but it doesn't know the answer either. However, it does know that the authoritative nameserver (NS) for freebsdwiki.net - the second level domain of the URL you wanted - is ns1.jrssystems.net. And just like a.root-servers.net, it gave you the corresponding A record before you could even ask. Next step: 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
Finally, we ask ns1.jrssystems.net for the last piece of the puzzle - www.freebsdwiki.net. Since ns1.jrssystems.net is authoritative for both the third (www) and second (freebsdwiki) subdomains of the .net top level domain, we are given the final answer to our query, instead of being handed off to another nameserver. And now that the DNS resolver has the right A record for the URL we wanted, it extracted 66.154.114.98 from it, handed that to your web browser, which then fetched the web page, and here we are.
