RSSAC FAQ
This page contains questions and answers to many of the most commonly asked questions of the RSSAC. It will be updated as the answers change, or as new questions become frequent.
If you have a question that is not listed below, or for further information or clarification, you may send a mail directly to ask-rssac@icann.org. If you wish to refer to a question in this FAQ, please include the number and title of the question in your email. The root server operators also maintain an FAQ.
List of Topics
- Number of Root Servers
- Anycast
- DNS and Networking
- Root Zone Integrity
- DNSSEC
- RSSAC
- RSSAC Caucus
- Common Misunderstandings
-
Number of Root Servers
1.1 Why are there 13 root name servers?
In 1985 there were four root servers. From 1987-1991 there were seven, and all were located in the U.S.A. By 1993 there were eight. At this point, a problem was encountered. RFC 1035 stipulates that "[DNS] messages carried by UDP are restricted to 512 bytes." Adding more root name servers would result in a priming response that exceeded 512 bytes. RFC 1035 does not provide a rationale for the 512 byte limit, but it is also worth noting that, at the time, there was a common requirement that IP packets on the Internet be limited to 576 bytes.
Root server operators realized that more name servers could be added if they could take advantage of DNS name compression. Thus, the proposal was made to give the root servers names in the root-servers.net zone. By 1995 the nine existing root servers had been renamed to "a.root-servers.net", "b.root-servers.net", and so on. In 1997, four more were added, bringing the total number of root server identifiers (RSIs) to 13.
Up until 1998, Dr. Jon Postel, as the administrator of IANA, had been the one to designate root server operators. Following his death in 1998, the number of operators has not changed, although a small number have changed hands over the years.
Since 1998, the landscape has changed in several ways. Each root server has added its own IPv6 address, and ICANN signed the zone with DNS Security Extensions (DNSSEC). Also, the size of messages carried over UDP has expanded using the Extension Mechanisms for DNS (EDNS) protocol extension. Together these changes have rendered both the 512 byte UDP limit and the 13 RSIs limit much less important.
In 2002, Internet Software Consortium (ISC, now Internet Systems Consortium) became the first root server operator to deploy IP anycast, although the WIDE Project had experimented with the technology earlier. Over the years, the other root server operators followed. Anycast allows each operator to provide the service from multiple distinct instances. While today there remain 13 RSIs, there are in fact more than 1500 anycast instances in operation throughout the world.
For a better understanding of the history of the root server system (RSS), please read RSSAC023v2: History of the Root Server System. If you are interested in the continued evolution of the RSS, please read RSSAC037: A Proposed Governance Model for the DNS Root Server System.
1.2 What was the math behind the 13 root server identifiers limit?
In 1997 the root servers were also acting as authoritative servers for the .COM, .NET and .ORG zones, and this added functionality placed an important restriction on how many RSIs there could be. Just as with the priming query for the root zone, querying the NS RRSET for the .COM, .NET and .ORG zones could not exceed the 512 byte limit, and since the same servers were serving these zones, the same limitation applied to all of them.
A DNS response packet also contains the complete question asked in the Question section. A response to a root priming query will always use 5 bytes for the Question section. The QNAME takes 1 byte, and the QTYPE and QCLASS each take 2, for a total of 5. However, for a .COM priming query the Question section could be considerably larger.
Purpose
Bytes
DNS Header
12
First NS record
31
12 Compressed NS records
(12 * 15) 180
13 A records
(13 * 16) 208
Question section QTYPE and QCLASS
4
Question section QNAME
?
=
435
Table 1: Explanation of bytes used in the root priming response
With 435 bytes in use, this left 77 bytes available for the Question section QNAME. At the time it was determined that 64 bytes would be enough to accommodate most queries sent for .COM, .NET, and .ORG. Adding another server would require 25 bytes, and since 435 + 64 + 25 > 512, it was decided to not add another server.
-
Anycast
2.1 Why do some operators have many anycast instances while other operators have only a few?
The Root Server Operators (RSOs) are independent organizations with different mandates, different operational models, and different sources of funding. These differences can affect the number of anycast instances, as well as other operational choices. Root server operators have a high degree of independence in how they deploy their network; see RSSAC042: RSSAC Statement on Root Server Operator Independence. All RSOs are committed to providing high quality root DNS service.
2.2 Are the number of anycast nodes unlimited, or limited to a certain number?
Anycast operation is defined and described in RFC 4786 "Operation of Anycast Services" and RFC 7094 "Architectural Considerations of IP Anycast." There is no inherent limit on the number of nodes in an anycast service.
2.3 The root servers are replicating the authoritative root zone and republishing it, then the anycast instances are republishing the data from them. What is the difference between these two kinds of republishing?
RSOs receive the authoritative zone data from the Root Zone Maintainer (RZM). Each RSO then uses its own internal system of distribution to deliver the zone to all of its sites and anycast instances.
2.4 We host an anycast instance of a root server in a local city. We are seeing that it is answering queries from all over the globe. How can I make it only answer queries from the local area?
This is really a matter of IP routing and how the RSO operates its anycast service. Some RSOs configure their routers and peering sessions so that the anycast instance only receives local traffic. Others configure them to receive global traffic, relying on the routing system to choose the best path through the network. If you observe undesirable behavior with a hosted server, you should discuss this issue with the RSO providing the service.
2.5 In 2016 there was a large attack on Dyn. Could the same thing happen to all the root server anycast instances?
Yes, at least in theory. That is one of the reasons that the RSS has many operators and many root server instances. The large number of anycast instances increases the capacity of the RSS and certainly helps in attack situations. Though the root server system has been globally attacked in the past, no attack has ever been successful in taking the whole system down.
2.6 How do I request an anycast instance of a root server for my organization?
Please reach out directly to root server operators using the contact information below. Similar to question 3.4, you could also instead consider running a local copy of the root zone, such as is described in RFC 8806, without being formally part of the root server anycast system.
The Internet Addresses Registry for Latin America and the Caribbean (LACNIC) also has a project called +Raices to promote the installation of anycast root server instances in the countries of the LACNIC region. More information can be found here.
Cogent Communications
US Department of Defense (NIC)
ICANN
Internet Systems Consortium, Inc.
NASA (Ames Research Center)
Netnod
RIPE NCC
https://www.ripe.net/analyse/dns/k-root/hosting-a-k-root-node
University of Maryland
University of Southern California, Information Sciences Institute
US Army (Research Lab)
Verisign, Inc.
WIDE Project
2.7 How can I determine which instance of a root server identity responds to my queries?
You can use the 'dig' utility from a Unix or Mac-based computer system to send special queries to a root server identity. The response will indicate which anycast site received the query.
You can use the NSID query option and then look for the reported NSID string in the OPT Pseudosection of dig's output:
$ dig +nsid @a.root-servers.net … ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ; NSID: 6e 33 2e 75 73 2d 77 61 73 2e 72 6f 6f 74 ("n3.us-was.root") …Each root server identity is free to choose their own anycast site naming scheme, but generally the sites are named using IATA airport codes or UN/LOCODE. Some root server identities publish their site naming conventions in the "Identifiers" section of their respective YAML files which are available on https://root-servers.org/.
-
DNS and Networking
3.1 How do recursive servers choose which root server to query, and which root server identifier should my recursive server prefer?
This is called the "server selection algorithm." The DNS protocol does not specify how a recursive name server should choose from among a set for a particular query. Thus, each recursive software vendor determines their own server selection algorithm. Some resolver implementations will "lock on" to the server with least latency, or one of the servers that has a latency similar to the fastest. Some resolver implementations choose the server at random each time, and some distribute the queries based on complicated formulas.
It is probably more reliable to let your recursive software do its job as designed, rather than trying to influence it to prefer or avoid particular servers.
3.2 Can you explain how DNS uses both UDP and TCP port 53?
Almost all DNS clients utilize UDP transport by default for queries. However, there are some situations when TCP needs to be used instead.
The most common use of TCP happens when a UDP response is truncated. Such truncation occurs when a server's response is too large to fit in a single UDP message. This depends on the client's advertised UDP buffer size, and any response size limits that the server may place on itself. When a client receives a response with the truncated bit set, the DNS protocol says that it must retry the query over TCP to get the full response.
Another use of TCP for DNS is zone transfers. Since whole zones are generally much larger than would fit in a single UDP message, it makes sense to perform these over TCP.
TCP can also come into play when a server finds itself under attack. The server might send clients truncated responses as a way to determine whether or not the sources are spoofed. Clients that establish TCP connections can be whitelisted as non-spoofed sources. Additionally, the technique known as Response Rate Limiting (RRL) will occasionally send truncated responses so that legitimate clients have an opportunity to receive responses over TCP, whereas the attack traffic will not retry.
DNS-over-TCP is mandatory to implement in DNS software. For additional information please refer to RFC 7766.
3.3 How can I decrease the latency between the recursive server I run and a root server?
First, you should carefully consider whether there is any real benefit to being closer to (more) root servers. The DNS makes heavy use of caching technologies. Because of this there is often little benefit to decreasing latency between a recursive server and a root server instance. Also, as mentioned in the response to question 3.1, resolver software algorithms will generally try to query the root servers with lower latency. So having high latency to some root servers will not necessarily result in queries to the root server system having high latency.
Analyze the traffic leaving your recursive name server for queries that are sent to root name servers. If you see more traffic than expected, you may be able to fix your applications or network configurations so they don't need to query the root so often. Use programs like the "dig" utility to measure actual latencies. If at least two root servers are within 100 milliseconds, that should generally be sufficient.
Use tools such as "traceroute" to explore the network path between your recursive server and the root servers your recursive name server is using. If you find something that doesn't make sense (such as routing through far away locations), ask your ISP if the routing can be adjusted.
For more information on DNS quality of service measurements, the Réseaux IP Européens (RIPE) Atlas project monitors the quality of service of the root service with its DNSMON project. The latency of most servers as measured by hundreds of RIPE Atlas anchors is below 60ms.
If there are no reasonably nearby root servers, then you could try to identify a nearby exchange point or data center where a root server could be located. Ask one or more of the root server operators if they would be willing to place a server there. Note, however, that if a location already has one root server, the operators usually won't want to place another one there. You can find operator contact information by visiting http://www.root-servers.org and locating the "Contact Email" buttons in the Root Servers section at the bottom of the page.
3.4 Can you set up a root server yourself by downloading the root zone file and validating the signature yourself?
RFC 8806 describes how to do this, as well as listing many warnings about possible downsides to doing so. Note that it requires DNSSEC validation. See also the LocalRoot Project.
3.5 How long will a recursive server cache information?
Every DNS record has a Time-To-Live (TTL) value assigned by the publisher of the zone. This determines how long a recursive name server or other client should cache the data for reuse. After this time, the recursive name server is expected to contact an authoritative server again for fresh data.
In the case of the root zone, some records are served with a 24-hour TTL and others with a 48-hour TTL. Some resolvers have maximum cache lifetimes, typically 24 hours.
3.6 Because caching will give wrong information after time, how can a resolver be updated with the correct DNS information?
If you suspect that the data in a recursive name server cache is stale, you can flush its cache or restart the server process.
3.7 What are DNS priming queries and responses?
DNS recursive resolvers need to prime their caches with specific data from the root zone before they can start answering regular queries. RFC 8109 describes what queries recursive resolvers send and the responses they expect from the root servers.
-
Root Zone Integrity
4.1 How do operators ensure that the root zone is properly replicated?
The transfer of the root zone file from the Root Zone Maintainer (RZM) to the individual RSOs occurs via the DNS zone transfer protocols (AXFR in RFC 5936 and IXFR in RFC 1995). These zone transfer messages are protected by the use of TSIG resource records as described in RFC 2845. These are reliable protocols and there are no known incidents of data corruption. Furthermore, because the root zone is signed, incorrect or falsified answers can be detected by DNSSEC validators. RSSAC encourages the use of DNSSEC validation where possible.
The RZM uses DNS NOTIFY defined in RFC 1996 for prompt notification of zone changes to alert the RSOs that a new (i.e., latest version) zone is available for copying or transfer.
4.2 What is ZONEMD and how can it protect the integrity of root zone data?
Because it is impossible to prevent any data corruption along any path it is important that resolvers validate all answers they receive using DNSSEC (see Section 5). Other mechanisms have been additionally deployed to ensure that each deployed root server instance properly serves data to the best of their ability. As discussed above, the use of TSIG by RSOs and the RZM ensures that record data is not corrupted during transfer.
RFC 8976 defines a mechanism for ensuring the integrity of a DNS zone file using a ZONEMD record that "provides a cryptographic message digest over DNS zone data at rest". As noted in a statement published by the root-server operators, RSOs will not enable ZONEMD verification for the first year after the initial publication of ZONEMD records. This is not deployed yet, but there are plans to do so in the future.
ZONEMD will enable recipients of a complete root zone to verify the zone contents for data integrity and origin authenticity. DNSSEC enables end-users of DNS signed data (which includes the root zone) to ensure the answers they have received are authentic, regardless of the path and servers that may have handled the data while in transit.
-
DNSSEC
5.1 Does DNSSEC make DNS queries or responses confidential?
No, it only adds a security layer to the DNS infrastructure by authenticating the origin of DNS data, as well as protecting its integrity.
5.2 Does DNSSEC make it more difficult to serve a copy of the root zone locally?
No, serving a local copy of the root zone simply means serving up-to-date copies of the root zone with no changes. The root zone comes from the Root Zone Manager (RZM) with all of the needed DNSSEC signatures in place.
For more information on how to serve the root zone locally see question 3.4 and RFC 8806.
-
RSSAC
6.1 Are RSSAC meetings open to everyone?
The RSSAC holds periodic teleconferences and meets at ICANN meetings. Minutes from meetings and teleconferences (where available) can be viewed here. To observe an RSSAC teleconference or a work session, please contact rssac-staff@icann.org for remote participation information.
Most RSSAC meetings held at ICANN meetings are open to observers, unless the meeting is marked as closed in the ICANN agenda. The RSSAC also holds public sessions at ICANN meetings where community members are invited to ask their questions.
6.2 What is the relationship between the RSSAC and the SSAC?
The RSSAC and the Security and Stability Advisory Committee (SSAC) are the two mostly technical advisory committees in the ICANN community. The scope of their work, however, differs. The RSSAC only concerns itself with the "operation, administration, security, and integrity of the Root Server System" and SSAC concerns itself with "matters relating to the security and integrity of the naming and address allocation systems of the Internet".
There is some overlap in the scope of the two groups. To keep the two groups aware of each other's work, the SSAC appoints a liaison to the RSSAC. Additionally, at ICANN meetings, the SSAC and RSSAC hold a joint meeting.
The SSAC is described in Section 12.2(b) of the ICANN Bylaws. Additional information can be found here.
6.3 How are RSSAC and RZERC related? Is the RZERC a subset of the RSSAC?
The Root Server System Advisory Committee (RSSAC) and the Root Zone Evolution Review Committee (RZERC) are separate committees within ICANN, although there are liaisons between them and individuals may serve on both committees.
The RSSAC charter states that it:
"..advises the ICANN Board and community on matters relating to the operation, administration, security, and integrity of the root server system." For more information on the role of the RSSAC please read, RSSAC033: RSSAC Statement on the Distinction Between RSSAC and Root-Ops.The RZERC charter states that it:
"..is expected to review proposed architectural changes to the content of the DNS root zone, the systems including both hardware and software components used in executing changes to the DNS root zone, and the mechanisms used for distribution of the DNS root zone."The following graphic helps to explain the roles of each group.
6.4 Is there a timeline on when we know the number of root servers RSSAC wants to have? When will the evaluation happen to determine the number of letters?
RSSAC has no preconceptions on the number of root servers or the number of RSOs that there should be. The current limit on the number of operators is technical, not administrative.
6.5 Where can I find RSSAC publications?
RSSAC publications are available on the RSSAC publications page. Of particular interest to people becoming acquainted with the root server system are RSSAC023v2: History of the Root Server System, and RSSAC026v2: RSSAC Lexicon.
-
RSSAC Caucus
Information about the RSSAC Caucus can be found on their main web page.
7.1 What is the difference between an RSSAC member and an RSSAC Caucus member?
The RSSAC consists of appointed representatives and alternates from each root server operator, as well as liaisons to and from various other groups. The RSSAC Caucus is comprised of DNS experts who have an interest in the Root Server System. Most (but not all) of the advice published by the RSSAC is created by the RSSAC Caucus while the RSSAC is the formal advisory committee that provides the final approval of publications for transmission to the ICANN board and community.
All RSSAC members are also RSSAC Caucus members. The list of RSSAC members can be found here. The list of RSSAC Caucus members can be found here. Information on joining the RSSAC Caucus can be found on the main RSSAC Caucus page.
7.2. Are RSSAC Caucus meetings open to everyone?
The RSSAC Caucus holds general meetings at ICANN Annual General Meetings and at every even-numbered IETF. All of these general meetings are open to observers. RSSAC Caucus work party meetings are not open to observers.
All RSSAC Caucus members are invited to participate in all general RSSAC Caucus meetings and RSSAC Caucus work party meetings.
7.3 Is there a limit to how many RSSAC Caucus members there can be?
No.
7.4 What are the time requirements of RSSAC Caucus members?
RSSAC Caucus members are expected to take part in work parties and participate on the RSSAC Caucus mailing list. Some members will be able to devote more time than others, and that certain work parties and document reviews require more time than others. However, RSSAC would generally like members to devote at least 4 hours per month on Caucus activities.
-
Common Misunderstandings
For an introduction on how the DNS works please read, The Internet Domain Name System Explained for Non-Experts by Daniel Karrenberg.
8.1 Do root servers control where Internet traffic goes?
No, routers and the BGP protocol determine the path that packets take through the network on their way from source to destination. The DNS provides a mapping from human-oriented names to IP addresses, and it is these IP addresses that routers ultimately use to determine where packets should go.
8.2 Are most DNS queries handled by a root server?
No, most are handled by recursive resolvers without any interaction with a root server from data they already have in their caches. A recursive resolver only interacts with a root server if it does not have unexpired information about top-level domains or the roots themselves in its cache. Almost all of the queries received by root servers result in a referral response which tells the recursive name server where next to ask its question.
8.3 Do any of the root server identifiers have special meaning?
None of the root server identifiers are special.
8.4 Are there only 13 root servers?
There are more than 1500 servers globally, but only 13 root server identifiers (RSIs), each of which uses one IPv4 and one IPv6 address and anycast routing.
8.5 Do the root server operators conduct operations independently?
The RSOs do operate independently, but they also coordinate closely with each other via RSSAC and other forums. For more information, see RSSAC042: RSSAC Statement on Root Server Operator Independence.
8.6 Do the root servers only receive the TLD portion of the DNS query?
Currently, root servers (and indeed all DNS servers) usually receive the entire query name in the DNS request. However, a new DNS feature has been specified which will only send the TLD portion of the domain name to the root servers when necessary.
RFC 9156 describes how recursive DNS servers can send only the smallest necessary part of the query name. This is called Query Name Minimization, or QNAME Minimization. QNAME Minimization works by having recursive DNS servers only send the necessary parts of a domain name to the servers they query. Recursive DNS servers utilizing QNAME Minimization should only send the TLD portion of the query of the root servers. This minimizes the amount of information on the wire and therefore provides better privacy for users querying the DNS.
