Anycast

The thirteen root name server names answer from 1,603 sites. That is part of the 2,045 instances the root server system counted on 19 September 2026. Our own IP lookup returns exactly one country for each of those addresses, because that is all a lookup can do.

Two answers show what that is worth. It places b.root-servers.net in Uruguay, where the registry that manages the block sits. The block's owner is listed as B-Root OPS in the United States. It places ICANN's l.root-servers.net in Islamabad, which is a real site of that address, and one of its 137. Public resolvers fare no better: 1.1.1.1 comes back as South Brisbane, the address in the registry record that also says the block is "Routed globally".

The idea was written down in November 1993, when finding a nearby server meant reading a list of them. The proposal suggested one address for the file search service of the day, so that anyone could reach the nearest copy without choosing. It described an experiment rather than a protocol, because the routing system already had everything it needed.

Operators then built the practice around it. The IETF's guide of December 2006 defines anycast as "making a Service Address available to a routing system at Anycast Nodes in two or more discrete locations". It warns that availability now "changes according to the location of the client". A review of January 2014 set out what the architecture can and cannot promise.

An anycast address tells you nothing about where a service is. Reading a geolocation database for one, or a registry record, gives one place out of hundreds. That is worth remembering whenever a target's address is checked before a job.

Which site answers depends on where your proxy exits. Two proxies in different countries reach different data centres of the same service, with different caches and sometimes different content, although the address is identical. Testing through the proxy you will use answers that question; the address alone does not.

Proxy exits themselves are ordinary addresses announced from one place. Anycast suits short, stateless exchanges such as DNS queries, and the IETF guide names long transactions as one of its limits. There is also a quieter trap. If your client resolves names through a public anycast resolver, the answer can be chosen for the resolver's site rather than for the proxy.