Skip to main content


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 If you wish to refer to a question in this FAQ, please include the number and title of the question in your email.

List of Topics

  1. Number of Operators
  2. Anycast
  3. DNS and Networking
  5. RSSAC
  6. RSSAC Caucus
  7. Common Misunderstandings
  1. Number of Operators

    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 zone. By 1995 the nine existing root servers had been renamed to "", "", 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 1000 anycast instances in operation throughout the world.

    For a better understanding of the history of the root server system (RSS), please read RSSAC023: 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.



    DNS Header


    First NS record


    12 Compressed NS records

    (12 * 15) 180

    13 A records

    (13 * 16) 208

    Question section QTYPE and QCLASS


    Question section QNAME






    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 accomodate 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.

  2. 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 How do you ensure that the root zone is properly replicated? Is there any chance of the root zone files getting corrupted by any attack or malware?

    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. This is a reliable protocol 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.

    2.3 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.4 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.5 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.6 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.

    2.7 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 7706, without being formally part of the root server anycast system.

    Cogent Communications


    US Department of Defense (NIC)



    Internet Systems Consortium, Inc.

    NASA (Ames Research Center)




    University of Maryland


    University of Southern California, Information Sciences Institute

    US Army (Research Lab)


    Verisign, Inc.

    WIDE Project


  3. 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. A 2012 paper describes the algorithm of popular implementations at the time.

    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 We know the DNS works on UDP 53, can you explain when DNS works on TCP 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 be closer to (more) root servers. 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 and locating the "Contact Email" buttons in the Root Servers section at the bottom of the page.

    3.4 Can you setup a root server yourself by downloading the root zone file and validating the signature yourself?

    RFC 7706 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 operator 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.


    4.1 Can DNSSEC protect from fast flux attacks?

    Not really. DNSSEC is designed to protect against data tampering, but not fast flux attacks.

    4.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 7706.

    4.3 It seems like DNS over UDP is limited to 512 bytes, and DNS over TCP is limited to 4096 bytes. If I sign my zone maybe the size will exceed MTU. Will it then get dropped by a firewall?

    DNS over UDP is no longer limited to 512 bytes. The Extension Mechanisms for DNS (EDNS), described in RFC 2671 and later updated by RFC 6891, defines how clients and servers can indicate support for message sizes greater than 512 bytes.

    TCP has never been limited to 4096 bytes. It is designed to deliver data of an arbitrary size.

    There are some legitimate concerns about the size of signed responses. When a DNS-over-UDP response exceeds the network MTU size, it will be fragmented. This has been identified as a security risk for cache poisoning. Some firewalls will block these fragments. For this reason, modern recursive resolvers are designed to use lower EDNS buffer sizes, and to retry queries with smaller buffer sizes. When the buffer size becomes small enough, the recursive name server will either receive a non-fragmented response, or a response with the truncated bit set, indicating it should retry over TCP.

  5. RSSAC

    5.1 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:
    " 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.


    5.2 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. RSSAC Caucus

    6.1 Is there a limit to how many RSSAC Caucus members there can be?


    6.2 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.

  7. Common Misunderstandings

    For an introduction on how the DNS works please read, The Internet Domain Name System Explained for Non-Experts by Daniel Karrenberg.

    7.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.

    7.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.

    7.3 Do any of the root server identifiers have special meaning?

    None of the root server identifiers are special.

    7.4 Are there only 13 root servers?

    There are more than 1000 servers globally, but only 13 root server identifiers (RSIs), each of which uses one IPv4 and one IPv6 address and anycast routing.

    7.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.

    7.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, new effort is underway to only send the TLD portion of the domain name to the root servers when necessary.

    In 2016, the IETF published RFC 7816, which 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. As of 2020, QNAME Minimization is relatively new and not yet widely deployed.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."