Thirteen addresses, hundreds of sites
What anycast actually does

The same address, announced from many locations
A single IP address, broadcast to the global routing table from dozens of physical locations simultaneously — that is anycast. It is not load balancing in the conventional sense, where a dispatcher decides where to send traffic. The decision happens in the network fabric itself, and it happens before a packet reaches any DNS server at all.
The mechanism is BGP, the Border Gateway Protocol that holds the internet's routing table together. Each anycast site announces the same prefix — say, a /24 containing the server's address — to its upstream providers. Routers pick the path with the shortest AS path or best local policy, using the same criteria they use for everything else. They do not know this is DNS. They do not need to. Whatever BGP considers the nearest announcement wins, and that site receives the query.
The consequence is geographic distribution without any client-side knowledge. A resolver in Tokyo reaches one instance; one in Frankfurt reaches another; one in São Paulo reaches a third. All three believe they are talking to the same address, and they are correct — the address is shared, but the machine is not.

Why the root servers run this way
The thirteen root server addresses were fixed before anycast existed as a widely deployed technique. When global query volume grew beyond what thirteen physical machines could absorb, the answer was not to change the protocol limit — it was to multiply each address behind BGP. A-Root, operated by Verisign, now responds from well over fifty sites. F-Root (ISC) and K-Root (RIPE NCC) are similarly distributed. The address stays the same; the infrastructure behind it expands as operators provision new nodes.
IANA coordinates the root zone itself, but the individual root server operators — twelve organisations covering the thirteen letters — each decide where and how many sites to run under their letter. According to root-servers.org ↗, the aggregate site count across all operators runs into the hundreds. The same BGP-based architecture lets a TLD operator deploy anycast for their own nameservers, and most large registries do.
What this means for failure
Anycast's failure modes are different from unicast's. When a site goes down, BGP withdraws the announcement, and traffic falls back to the next-nearest site within whatever convergence time BGP requires — typically seconds to a few minutes. For most resolvers, this looks like a brief timeout followed by a successful retry. The failure is local and contained; a data-centre fire in Amsterdam does not take the address offline globally.
The subtler failure is a misconfigured announcement. If a site continues to announce the prefix while the server behind it is dead or misbehaving, BGP keeps routing traffic to it, and resolvers see consistent failure for that destination. The routing layer has no awareness of application-layer health. Operators compensate by pairing the BGP announcement with local health checks that withdraw the route automatically if the server stops responding correctly — but that automation is their responsibility, not a protocol guarantee.
Anycast also breaks assumptions that treat an IP address as identifying a single machine. DNSSEC validation is unaffected because it operates on the signed content, not the transport path. But stateful protocols — TCP sessions, in particular — can misbehave if a route flaps mid-connection, since successive packets may reach different nodes. DNS over UDP is naturally tolerant; DNS over TCP ↗ and DNS over TLS require operators to think carefully about session affinity at anycast boundaries.
When a site goes down, BGP withdraws the announcement, and traffic falls back to the next-nearest site within whatever convergence time BGP requires — typically seconds to a few minutes.
The elegance of the arrangement is that it requires no changes to resolvers, no protocol extensions, and no coordination beyond BGP peering agreements. Routing infrastructure that already existed is doing the work. That is partly why anycast scaled so cleanly as the root grew: the distribution mechanism cost nothing in the protocol layer. It borrowed leverage from the routing table, and the routing table did not notice.

The elegance of the arrangement is that it requires no changes to resolvers, no protocol extensions, and no coordination beyond BGP peering agreements.