Resolution · stage 02

Anycast

The same address answered by many machines, and the network decides which.

Stage 02 of six/Resolution, piece 3 of 3/Short piece/Next: The certificate chain

A world map printed and pinned to a wall with coloured pins marking sites, angled view
Stage 02 · ResolutionSame IP, many machines — BGP routes each packet to whichever instance is topologically nearest

One address, many answers

An IP address is normally a single destination. Anycast breaks that assumption: the same address is announced from multiple physical locations simultaneously, and the network routes each arriving packet to whichever of those locations is topologically nearest. No single machine holds the address; all of them do.

The mechanism runs on the same routing protocol — BGP — that knits the internet together. Each node in the anycast cluster advertises the shared address to its upstream peers. BGP, picking paths by prefix and AS-path length, naturally funnels a query toward the closest announcement. The machine that answers is the one the network finds first, not one chosen by the application.

DNS resolvers lean on this heavily. The thirteen logical root server addresses — named A through M — are each served by dozens or hundreds of physical instances scattered across continents. A query from Tokyo lands at a different root instance than the same query from Frankfurt, even though both send to the same IP. Response times stay low not because any one machine is fast, but because the path to some instance is short wherever you are.

The tradeoff is that anycast is stateless by design. Each packet is routed independently, so a flow that spans multiple packets — a TCP connection, a TLS handshake — could in principle split across two instances if routing changes mid-session. In practice, BGP route changes are rare enough that short-lived UDP exchanges (DNS chief among them) work cleanly, and operators size their clusters to keep routes stable for the duration of a TCP session. But it is a real constraint, which is why anycast suits query-response protocols more naturally than streaming ones.

If an instance goes offline, its BGP advertisement withdraws, and traffic shifts to the next-nearest node automatically — no DNS update, no failover script, no TTL to wait out. The TTL and staleness problem that delays ordinary DNS changes simply does not arise here, because the address itself never changes.

A hand-drawn tree diagram of domain hierarchy on paper, pen resting on it, desk light
Also in ResolutionThe name is resolved by walking down a hierarchy from the root, with caching at every step. DNS from the rootPhoto: Domain-name-system · Wikimedia Commons
Stage 02

The machine that answers is the one the network finds first, not one chosen by the application.

A data-centre aisle in cold blue light with closed doors
Stage 02 · Resolution The stage in a room: the same address answered by many machines, and the network decides which.