Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  Name Systems and TCP/IP Name Registration and Name Resolution            9  TCP/IP Name Systems: Host Tables and Domain Name System (DNS)                 9  TCP/IP Domain Name System (DNS)                      9  DNS Name Servers and Name Resolution                           9  DNS Name Server Concepts and Operation

DNS Zone Management, Contacts and Zone Transfers 1 2 3 DNS Name Server Caching, Negative Caching and Data Persistence

Ensuring Access to the Root Name Servers

Clearly, the root name servers are extremely important to the functioning of the DNS system as a whole. If anything were to ever happen to cause the root name servers to stop operating, the entire DNS system would essentially shut down. For this reason, there obviously isn't just one root server, nor are there two or three; there are (at present) thirteen different root name servers.

In fact, there are actually far more than thirteen physical servers. Most of the thirteen name servers are implemented as clusters of several independent physical hardware servers. Some are in fact distributed collections of servers that are in different physical locations. The best example is the “F” root server, which has been implemented as a set of over a dozen mirrors in various places around the world, to provide better service.

The principles of redundancy that I mentioned are a good idea for choosing a secondary name server for a regular domain, obviously apply that much more to the root. This is why the various physical devices that comprise the thirteen root servers are all located in different places all around the globe. Many of them are in the United States, but even these are in many locations throughout the country (albeit concentrated in a couple of “hot spots” in California and near Washington, DC) and are set up to use different networks to connect to the Internet.

The root name servers are of course rather powerful; despite there being several dozen pieces of hardware to spread the load, they must each handle large amounts of data, 24 hours a day. They are run by networking professionals who ensure that they function efficiently. An Internet standard, RFC 2870 (Root Name Server Operational Requirements), spells out the basic rules and practices for the operation of these name servers. It specifies extensive procedures for ensuring the security of the servers, and for avoiding performance problems due to their pivotal role.

Despite all the efforts taken to ensure that the root servers are widely distributed and secure, they still collectively represent a point of weakness in the global Internet. Millions and millions of people depend on these servers. There have been incidents in the past where rogue elements on the Internet have attempted to disrupt DNS by attacking the root name servers. One widely-publicized incident was a denial of service (DoS) attack against the root servers on October 21, 2002. The attack failed, but it significantly raised awareness of the importance of these servers and how essential DNS security is.

DNS Zone Management, Contacts and Zone Transfers 1 2 3 DNS Name Server Caching, Negative Caching and Data Persistence