Anycast

Anycast is a beautiful lie. The same IP address exists in Tokyo, London, and New York simultaneously. When you connect to it, you reach whichever one is "closest"—and everyone's closest is different.

This isn't a trick or a workaround. It's how the Internet's most critical infrastructure actually works. The DNS root servers, Google's 8.8.8.8, Cloudflare's 1.1.1.1—these addresses don't point to a single server. They point to hundreds of servers, scattered across the globe, all pretending to be the same destination.

How One Address Becomes Many

Normally, an IP address is like a street address: one location, one building. Send a letter there, it arrives at that specific place.

Anycast breaks this. An organization deploys servers in New York, London, Tokyo, and Sydney—and gives them all the same IP address. Then each location announces to its neighbors: "Hey, I'm 192.0.2.1, and you can reach me through here."

This announcement propagates via BGP, the routing protocol that glues the Internet together. Every router learns multiple paths to 192.0.2.1. And BGP has a simple preference: shorter paths are better.

So when you in Los Angeles send packets to 192.0.2.1, your ISP's routers check their options. New York is two hops away. Tokyo is four. Sydney is five. New York wins. Your packets go to the New York server.

Meanwhile, someone in Singapore sends packets to the exact same address. Their ISP's routers see Tokyo as closest. Their packets go to Tokyo.

Same address. Different destinations. The Internet's routing fabric makes the decision invisibly, instantly, for every packet.

The Magic of Automatic Distribution

No load balancer sits between users and servers. No traffic director examines each request. The Internet itself is the load balancer.

This is why anycast feels like magic. You deploy servers, announce the same address from each location, and traffic automatically flows to nearby instances. Users in Europe hit European servers. Users in Asia hit Asian servers. You didn't configure this. BGP did.

Adding capacity is equally elegant. Deploy a new server in São Paulo, announce the same prefix, and South American traffic starts flowing there. Remove a server by withdrawing its announcement, and traffic reroutes to the next-closest location. The Internet adapts.

Where Anycast Lives

DNS Root Servers

The DNS root server system reveals something genuinely strange: there are only 13 root server addresses (a.root-servers.net through m.root-servers.net), but hundreds of physical servers answer them. The Internet's phone book has 13 entries that each point to everywhere at once.

When your device queries a root server, you're automatically routed to a nearby instance. Fast responses, built-in redundancy, and attacks that try to take down "the" root server instead scatter across dozens of locations.

Public DNS

Google's 8.8.8.8 and Cloudflare's 1.1.1.1 are anycast addresses. These memorable IPs exist in hundreds of locations. No matter where you are, you get a fast response because "8.8.8.8" is nearby—your nearby, wherever that is.

Content Delivery Networks

CDNs use anycast to route you to nearby edge servers. Request an image, get it from a server a few milliseconds away instead of across an ocean.

DDoS Protection

When attackers flood an anycast address, they're actually flooding dozens of servers simultaneously. Each location absorbs a fraction of the attack. What would overwhelm a single server barely registers when distributed globally.

Why Anycast Works So Well

No Configuration Per User: You don't set up regional DNS or geographic load balancing. One IP serves everyone, everywhere.

Automatic Failover: If Tokyo goes down, packets to "Tokyo" automatically reroute to the next-closest server. Users experience a brief hiccup, not an outage.

Latency Reduction: Physics can't be cheated—light takes time to travel. Anycast cheats geography instead, putting servers close to users.

Simplified Operations: One address to publish, one address for users to remember, one address in your documentation. The complexity hides in the routing layer.

The Catches

Routing Isn't Geography

BGP routes to the topologically nearest server (fewest network hops), not the geographically nearest. Sometimes the "closest" server is actually farther away in miles. Network topology and physical distance don't always align.

Stateful Connections Are Fragile

Anycast shines for stateless protocols like DNS: question, answer, done. TCP connections that persist for minutes or hours are riskier. If routing shifts mid-connection, your packets suddenly arrive at a server that's never heard of you. The connection breaks.

Modern implementations work around this—keeping anycast nodes stable, accepting occasional connection resets, using short-lived connections. But the fundamental tension remains: anycast assumes every packet can go anywhere, while TCP assumes packets go to the same place.

Load Distribution Is Accidental

Traffic flows based on routing, not actual server load. One location might be overwhelmed while another sits idle—BGP doesn't know or care how busy servers are.

Operational Complexity

Coordinating announcements across locations, debugging routing issues when multiple servers share an address, ensuring consistent behavior globally—anycast operations require expertise.

The Fundamental Insight

Anycast inverts the normal relationship between addresses and locations. Instead of "this address means this place," anycast says "this address means whichever of these places is closest to you."

It's a lie everyone agrees to believe. And because everyone believes it, it works. Your packets find the nearest server. The server responds. You never know there were other options, other servers, other paths not taken.

The Internet's most reliable services depend on this collective fiction. When you query a DNS root server or use 1.1.1.1, you're participating in an elaborate agreement where one address means many places, and "where" depends entirely on who's asking.