Skip to main content
Resources

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.

Number of Operators

  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 [PDF, 374 KB]. At this point, a problem was encountered. RFC 1035 stipulates that "messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers)." 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 expectation that IP packets on the Internet were 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 and in 1997, four more had been added, bringing the total to 13 and again reaching the 512 byte limit.

    Up to that point in time 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 that time, the landscape has changed in several ways. Each root server has added IPv6 addresses and signed the zone with DNS Security Extensions (DNSSEC). The size of messages carried over UDP has expanded using the Extension Mechanisms for DNS (EDNS) protocol extension. Common Path Maximum Transmission Unit (PMTU) values in today's Internet are governed by the Maximum Transmission Unit (MTU) of an Ethernet frame, which is 1500 bytes including the IP header.

    In 2002, Internet Systems Consortium (ISC) became the first root server operator to deploy IP Anycast. Over the years the other operators followed. Anycast allows each operator to provide the service from tens or hundreds of distinct instances. While today there remain 13 root server identities, there are in fact more than 800 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 [PDF, 374 KB]. If you are interested in the continued evolution of the RSS please read the latest RSSAC workshop report. Currently the latest workshop report is, RSSAC029: Report from the RSSAC October 2017 Workshop [PDF, 64 KB].

Anycast

  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. All RSOs are committed to providing high quality root DNS service.

  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, since the root zone is signed, incorrect or falsified answers can be detected by DNSSEC validators. RSSAC encourages all recursive name server operators to enable DNSSEC validation when possible.

  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.

  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.

  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 answers 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, get in touch with the RSO providing the service.

  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 Root Server System (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.

DNS and Networking

  1. How do recursive servers choose which root server to query, and which root server identity 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 can determine their own server selection algorithm. Some implementations will "lock on" to the server with least latency, or one of the servers that has a similar latency to the fastest. Some 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 best to let your recursive software do its job as designed, rather than trying to influence it to prefer or avoid particular servers.

  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 might be used instead.

    Perhaps 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, it should 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.

    For additional information on DNS-over-TCP please refer to RFC 7766.

  3. How can I decrease the latency between the recursive server I run and a root server?

    First, you should carefully consider whether your truly need 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 Unix dig utility to measure actual latencies. If at least a handful of root servers are within 100 milliseconds, that should generally be sufficient. The vast majority of DNS queries should be getting answered from the cache of the local recursive DNS server.

    Use tools such as traceroute to explore the network path between your recursive server and the set of root servers. 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.

  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.

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

  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 always flush its cache or restart the server process.

DNSSEC

  1. Can DNSSEC protect us from fast flux and super fast flux attacks?

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

  2. Does DNSSEC complicate the possibility of someone running their own root server?

    Yes, because the zone must be regularly updated before the DNSSEC signatures expire.

  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 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. Some firewall products will block these fragments. For this reason, modern recursive name servers are designed to retry queries with lower advertised EDNS buffer sizes. When the buffer size becomes low enough, the recursive name server will either receive a nonfragmented response, or a response with the truncated bit set, indicating it should retry over TCP.

RSSAC

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

    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.

    RSSAC FAQs

  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 Root Service Operators, there should be. The current limit on the number of operators is technical, not administrative.

RSSAC Caucus

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

    No.

  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.

Common Misunderstandings

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

  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.

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

  3. Do any of the root server identities have special meaning?

    None of the root server identities are special.

  4. Are there only 13 root servers?

    There are more than 800 servers globally, but only 13 technical identities.

  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.

  6. Do the root servers only receive the TLD portion of the DNS query?

    Historically, root servers (and indeed all DNS servers) received 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. 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 2018, 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""icann.org"" is not an IDN."