The Domain Name System (DNS) is a directory system for looking up some types of information on the Internet. Its most common use is to map human-understandable online resource names (such as www.example.com and human@example.com) to IP addresses (such as 192.0.2.1 or 2001:db8::1) that are understood by computers.
The DNS is
DNS was standardized in 1987 in Internet Standard RFCs 1034 and 1035 and has been extended since then repeatedly by the IETF.
As discussed above, the DNS is hierarchial -- but there still needs to be a single place to start. There are many Top Level Domains (TLDs) (.org, .com, .biz, .uk, etc) and information about them changes occasionally. Thus, the purpose of the DNS root domain is to be the stable starting place to find current up to date information about each TLD.
The DNS Root Server System (RSS) is the collection of computers that provide service for the DNS Root domain. This service is provided by multiple independent Root Server Operators (RSOs -- see "How many root operators are there?"), that serve the DNS Root zone from thousands of sites (see "How many root servers are there?").
DNS RSS latency has almost zero effect on user-visible latency for typical comptuer use.
Because computers look up information about the Internet all the time, the DNS uses caching, where the querier remembers what it looks up and reuses that answer for some time. In addition, people often use a common computer to query the DNS, allowing answers given to other users can be also be further reused. For these reasons, although logically the DNS root is part of very lookup, only a tiny fraction (typically less than 1%, according to the study mentioned below) of queries require a new contact with the root.
Because most answers for TLDs are usually cached, it is very rare that any user's query is dependent on the speed of the answers from the RSS. (For an academic study evaluating this question, see the paper Anycast in Context: A Tale of Two Systems.
The previous question was about latency -- how fast answers come from the DNS root. Now we consider availability -- is the Root Server System available to answer at all?
Because the DNS root is logically part of every DNS resolution, the computer resolving a DNS name needs to know about the DNS root, so availability of the DNS Root Server System is important.
However, the DNS Root Server System is highly cached (as described above) and also replicated, with literally thousands of sites (see the current list of sites at root-servers.org), and those sites are run by multiple independent organizations. The Root Service Operators continually take steps to pro-actively mitigate threats to the Root Server System.
Although the DNS Root Server System has reported some events in the past where partial service degradation occurred, (most recently in 2016) the end result was still that "There are no known reports of end-user visible error conditions" and "The DNS root name server system functioned as designed, demonstrating overall robustness in the face of large-scale traffic floods observed at DNS root name servers."
Academic work has shown the DNS caching is very effective at protecting against attacks shorter than the cache duration (see Cache Me If You Can: Effects of DNS Time-to-Live). For the DNS root, caching lasts up to 2 days.
Currently there are 12 root server operators, whose identities you can see at the top of root-servers.org home page.
The number of root server instances changes (generally increases) over time. The current count of root server instances is shown just below the map on the home page.
Different operators deploy a different number of instances. You can see the per-operator instances, including their locations, by clicking on the letters at the bottom of the home page.
In each operator's list of sites, some instances are marked as global (globe icon) and some are marked as local (flag icon). The difference is in how widely available that instance will be, because of how routing for that instance is done. Recall that the routes for an instance are announced by BGP, the inter-domain routing protocol.
For global instances, the route advertisement is permitted to spread throughout the Internet, i.e., any router on the Internet could know the path to that instance. Of course, for a particular source, the route to that instance may not be the optimal route, so some other instance could be chosen as the destination.
With a local instance, however, the route advertisement is limited to only nearby networks. For example, the instance may be visible to just one ISP, or to ISPs that connect at a particular exchange point. Sources from farther away will not be able to see and query that local instance.
All operators provide service to the entire Internet through at least one global instance. Some operators may also choose to deploy local instances, depending on their own needs and requirements, and those of their provider partners.
Refer to RFC 4786 (section 4.4.6 in particular) for further details.
You may contact individual operators by finding their published email addresses linked off the home page. Find the Root Servers section and click on the individual letters. Then look on the right side of the page for a blue "Contact Email" or "Homepage" link. You may contact the root server operators collectively by writing to info@root-servers.org.
If you believe that your area of the Internet is underserved with respect to root zone service, you may inquire with individual operators about locating an instance nearby. Root server instances are generally located at data centers and exchange points. Different operators will have different requirements for providing instances at remote locations. Below are some links to pages of operators that offer hosted instances:
The root server operators are committed to providing service to all users, all networks, and all top-level domains equally. Such commitments are backed by a number of published policy documents and protocol specifications:
Correspondence to root server operators containing requests to block certain countries, networks, or top-level domains may be politely declined or ignored.
The root servers respond to all technically valid queries, with the following exceptions: