Root servers, anycast & traffic steering

The root zone is the smallest important file on the internet. It holds no web sites and no mail servers. It holds one thing: for every top-level domain, from com to nyc to jp, the names and addresses of the servers that run it, plus the signatures that let a resolver trust them. A resolver that has never seen .example asks the root, and the root replies "not me, ask these servers", a referral. Chapter 3 follows that walk step by step.

The servers that publish the root zone are known by thirteen names, one per letter. IANA lists them, and the table below is copied from that list. Each letter is a root server identity: a name, one IPv4 address and one IPv6 address, run by one organization. Twelve organizations share the thirteen letters, because Verisign operates two of them.

Thirteen identities, but not thirteen computers. When root-servers.org counted on the day this chapter was written, the system had 2,049 operational instances: separate server sites, each answering for one of the letters. Some letters run at hundreds of sites, others at a handful, and the total keeps growing. Every instance of, say, k-root answers on k-root's single address. Which one you reach depends not on where you are on a map, but on how the internet's routing reaches you. That is anycast, and it gets its own section below.

The operators are deliberately different kinds of organizations: universities, government agencies, a registry, a regional internet registry, non-profits and commercial firms, spread over several countries. They run different server software on different hardware, under a shared set of service expectations published by ICANN's Root Server System Advisory Committee. If one operator's software has a bug or its network has a bad day, eleven others are not affected by the same mistake. Diversity is the design.

The number is not arbitrary and not magic. It comes from the size of one packet. RFC 1035, in 1987, limited a DNS message over UDP to 512 bytes, because at the time some networks could not carry larger packets without breaking them up, and some firewalls dropped anything bigger. A resolver starting up asks a root server for the list of root servers, and the whole answer, every name and every address, had to fit in those 512 bytes.

ICANN's history of the root server system (RSSAC023) tells it plainly. By 1993 the list had grown until the answer was close to 512 bytes. The fix, carried out in 1995, was to rename every root server into one shared domain, root-servers.net. Inside a DNS message a repeated name can be replaced by a two-byte pointer to its first appearance (the compression scheme of Chapter 2), so the shared tail is written once instead of thirteen times. The bytes saved left room for four more servers, and in January 1997 j, k, l and m were added. That was thirteen, and there it stayed.

So the honest summary is this: thirteen is the number that fit in a classic 512-byte answer with the names compressed and some room to spare, and changing it since would have meant every resolver in the world reconsidering its assumptions for little gain, because anycast lets each letter grow without limit anyway. You can do the arithmetic yourself below.

The root servers publish the root zone; they do not write it. Changes start with the operator of a top-level domain, which asks IANA to update its entry, for example to change name servers. IANA, run today by Public Technical Identifiers, an affiliate of ICANN, checks the request and passes it on. The Root Zone Maintainer, a role Verisign performs, builds the new zone file, signs it (the key-signing key and its ceremonies belong to Chapter 11) and distributes it to all twelve operators, who load it onto every instance. Anyone can download the same file from IANA, which matters for the local copies described below.

A resolver that has just started knows nothing, not even who the root servers are. It ships with a small file of root hints, the names and addresses of the thirteen letters as they were when the file was made. Addresses do change from time to time, and a resolver built years ago may carry an old list. So the resolver does not trust its hints for long. Its first act is a priming query, defined as a best practice in RFC 8109: ask any address from the hints for the name servers of the root, . NS, and replace the hints with the live answer.

Look at the flags. aa means the answer is authoritative: it comes from the root zone itself. The Answer section has thirteen NS records and the Additional section has the addresses: 26 of them, plus the EDNS pseudo-record, makes 27. RFC 8109 points out that the A and AAAA records alone are larger than 512 bytes, which is why a resolver should send priming queries with EDNS(0) and accept answers of at least 1,024 bytes. If some addresses are left out anyway, the resolver asks for them directly.

There is a further step some resolvers take: not asking the root at all. RFC 8806 describes how a resolver can run its own copy of the whole root zone, fetched from IANA or the root servers and checked against its DNSSEC signatures, served only on the loopback interface of the same machine. The resolver then consults that local copy instead of a remote instance. The motive is resilience and privacy: lookups for names that do not exist, which are a large share of root traffic, never leave the building, and an attack on the root servers does not stop this resolver. The RFC is strict about one thing: the local copy must answer only the resolver on the same host, never anyone else.

An ordinary address belongs to one machine in one place. Anycast breaks that rule on purpose. The operator announces the same block of addresses, the same prefix, into the internet's routing system from many sites at once. Every router that hears the announcement from several directions keeps the one it likes best, by the rules of BGP covered in Dynamic routing. For this chapter it is enough to treat that as "lowest cost wins". A packet sent to the address follows each router's preferred path and arrives at whichever site that path ends at.

The set of users who end up at one site is that site's catchment. Catchments are made by routing, not by geography. A network in Mexico that buys its transit from a provider in Virginia will reach the Virginia site, even if there is a site in California much closer on the map. A network in West Africa connected through London will be served from Europe. Measurement projects such as RIPE Atlas show this all the time: the "nearest" instance in routing terms is often not the nearest in kilometres.

DNS suits anycast unusually well, for a plain reason: most DNS exchanges are one UDP packet in each direction. There is no connection to keep, so if routing changes between one question and the next, the next question simply lands at a different site, which has the same data and gives the same answer. RFC 7094 calls UDP the lingua franca of anycast for this reason. TCP is harder, because a connection's packets must all reach the same site. In practice routes are stable enough that DNS over TCP to anycast works, but RFC 4786, the operators' guide, warns that a route change in the middle of a connection breaks it, and that operators should watch for paths that flap.

Anycast gives three things at once. Nearness: most users reach a site a short routing distance away, which usually means a short time. Capacity: load spreads across sites in proportion to their catchments. And containment: if a flood of traffic comes from one part of the internet, it lands on the sites in that part, and users elsewhere are served by sites the flood never reaches. RFC 7094 lists the costs too: you cannot easily tell from outside which site answered, catchments can be lopsided, and a site that is up but broken will keep attracting its catchment until someone withdraws its route.

Root operators also choose how far each site's announcement spreads. root-servers.org marks every instance as global or local. A global instance's route is allowed to spread through the whole internet. A local instance's route is limited to nearby networks, perhaps a single internet exchange, so only those networks can reach it. Every operator keeps at least one global instance, so the whole internet is always served.

The root servers popularised anycast for DNS, but the technique runs all the way down. Operators of large top-level domains serve them from anycast networks, and so do the companies that host DNS for many customers. A DNS hosting provider will usually give you a handful of name server names for your zone; behind each name is an anycast address served from dozens or hundreds of sites. Large public resolvers are anycast too, which is why one easy-to-remember address works from anywhere.

Bigger operators often spread a zone across more than one anycast network, with different name servers on different address blocks and, ideally, different providers. If one network's routes are withdrawn by mistake, or one provider is flooded, resolvers retry another name server from the NS set and carry on. The rule is the same as for the root: more than one of everything, and nothing that fails for the same reason at the same time.

Because every site answers on the same address, you need a way to ask "which one did I reach?". There are two common ones. The older is a special query in the CHAOS class for hostname.bind or id.server, documented in RFC 4892, to which many servers reply with an operator-chosen site name. The newer is the NSID option of RFC 5001, an EDNS flag that asks the server to add its identifier to any answer. Both are harmless to send and widely used in measurement.

Anycast steers by routing. There is a second way to send people to a nearby server, and it is done entirely in DNS: give different people different answers. Ask for the address of a big site's www from Tokyo and from São Paulo and you may well get different addresses, each pointing to a server close to the asker. The authoritative server is making a choice every time it answers.

The catch is that the authoritative server never sees the user. It sees the resolver that is asking on the user's behalf. So the simplest form of steering, usually called GeoDNS, looks up the resolver's address in a location database and picks the server nearest to that. When the resolver sits at your ISP in your city, that works well. When it does not, for example when you use a public resolver whose nearest site to you is in another country, or a company network that sends all lookups to one head office, the answer is tailored to the resolver's location, not yours, and you get sent to a server far away.

EDNS Client Subnet (ECS), described in RFC 7871, is the patch for that. The resolver adds an EDNS option to its query carrying the first part of the user's address: a prefix, such as the first 24 bits of an IPv4 address. The authoritative server can then choose by the user's network instead of the resolver's, and it replies with a scope: the prefix length its answer is good for, so the resolver knows which other users can share the cached answer.

ECS is useful and it has a price, which RFC 7871 itself spells out in a privacy note at the top of the document. Part of the user's address now travels to every authoritative server the resolver talks to, and it can be read by any network the query crosses if DNS is not encrypted. To limit that, the RFC tells resolvers to cut the address short: 24 bits for IPv4 and 56 bits for IPv6. A /24 covers 256 IPv4 addresses, a small slice of one provider's network; a /56 in IPv6 is typically what an ISP hands one customer, so it usually identifies a household. That is precise enough to route well and still a lot more than "somewhere in this country". Some resolvers send no ECS at all, as a privacy choice; others send it selectively. Chapter 12 takes resolver privacy further.

ECS also costs cache. Without it a resolver keeps one answer per name. With it, it keeps one answer per name per scope prefix, so a popular name may be cached hundreds of times over, once for each block of users, and each copy expires on its own. Hit rates drop and upstream traffic rises. The steering lab counts this for you.

Once an authoritative server is choosing answers, location is only one input. Managed DNS services offer a family of policies, under various product names, that all work the same way: keep a set of possible answers and pick from them on each query.

• Weighted: answer A 90 percent of the time and B 10 percent. Used to shift a slice of traffic to a new data center or a new release, then turn the dial.
• Latency-based: like GeoDNS, but chosen from measured round-trip times between networks and sites rather than from a map.
• Failover: answer with the primary while health checks say it is up; when checks fail, answer with the backup instead.

All of them run into the same wall: caching. Whatever the authoritative server decides, a resolver holds the answer for its TTL and keeps handing it out. That is why steered names use short TTLs, often 30 to 300 seconds, where an ordinary record might use an hour or a day. A short TTL makes the dial responsive, and it costs more queries to the authoritative servers and a little more waiting for users when caches miss. Chapter 4 covers the trade in general.