What is Anycast?

When you type 8.8.8.8 into your DNS settings, you're not connecting to a single server. You're reaching one of hundreds of servers scattered across six continents, all sharing that exact same IP address.

How is this possible? The Internet's routing system automatically delivers your request to whichever server is "closest"—not geographically, but in network terms. This is anycast: one address, many destinations, automatic selection.

It powers the infrastructure that must never fail: DNS root servers answering billions of queries daily, content delivery networks serving most of the web's images and videos, DDoS mitigation systems absorbing terabit-scale attacks.

What Makes Anycast Different

Anycast inverts how we normally think about load balancing.

Traditional load balancers sit between users and servers, making explicit routing decisions. DNS-based load balancing returns different IP addresses to different users. Geographic routing uses application logic to pick endpoints.

Anycast does none of this. You don't program the load balancer—you give the network a question and let it figure out the answer. Announce the same IP address from data centers worldwide, and the Internet's routing system automatically delivers each request to the nearest one.

The routing infrastructure becomes the load balancer. No central controller. No configuration updates when you add servers. The network handles it.

Four Ways to Route Traffic

The Internet has four fundamentally different routing methods:

Unicast sends traffic from one sender to one receiver. This is most Internet traffic—HTTP requests, emails, video streams. One source, one destination.

Broadcast sends traffic to every device on a local network, whether they want it or not. ARP and DHCP use broadcast. It floods networks with traffic most devices ignore. IPv6 eliminated it entirely.

Multicast sends traffic to devices that explicitly opted in. IPTV uses multicast to send one video stream to thousands of subscribers simultaneously, rather than thousands of duplicate streams.

Anycast sends traffic to the nearest member of a group. Multiple servers announce the same IP address. The routing system picks the closest one automatically.

How Anycast Works

Anycast relies entirely on BGP—the Border Gateway Protocol that holds the Internet together.

Here's what happens: Google announces 8.8.8.8 from data centers in Virginia, California, Tokyo, London, São Paulo, and dozens of other locations. Each announcement propagates through the Internet as routers share information with their peers.

When you send a request to 8.8.8.8, every router along the path asks the same question: what's the best route to this address? The primary metric is AS-path length—how many autonomous systems (distinct networks) the traffic must cross. Shorter paths win.

Your request arrives at whichever server advertises 8.8.8.8 via the shortest network path. If that server fails, BGP withdraws the route announcement. Traffic shifts to the next-best path within seconds, automatically.

"Nearest" Doesn't Mean What You Think

Here's where intuition fails completely.

A user in Mumbai might reach a server in Singapore instead of one in Mumbai—even though Mumbai is physically closer. Why? Because the network path to Singapore crosses fewer autonomous systems.

This isn't a quirk. It's fundamental. The Internet's topology doesn't follow geography.

Your intuition about "closer" is built on maps you can see: roads, cities, coastlines. The Internet's map exists only in routing tables, shaped by business deals between carriers, undersea cables that cross oceans at unexpected angles, and peering agreements that create shortcuts invisible from the surface.

The topologically closest server wins. Always. Geography is irrelevant.

Where Anycast Powers the Internet

DNS root servers run entirely on anycast. The 13 root servers (A through M) operate over 1,950 instances across 1,500+ sites worldwide¹. When you query a root server, you're reaching one of these distributed locations—never the same physical machine twice in a row.

Public DNS resolvers depend on anycast too. Google's 8.8.8.8 operates from data centers globally, handling roughly 30% of all DNS traffic². Cloudflare's 1.1.1.1 runs across 330 cities worldwide³.

Content delivery networks use anycast to route traffic to edge servers. A single anycast IP represents thousands of edge locations, automatically directing users to nearby caches. Cloudflare, Akamai, Amazon CloudFront, and Fastly all build on this.

DDoS mitigation gains inherent protection from anycast. When attackers flood a single IP with traffic, anycast spreads that traffic across dozens or hundreds of servers instead of overwhelming one target.

During a November 2015 attack on DNS root servers—sustained traffic at 100 times normal load—anycast prevented disruption. The attack distributed across multiple sites automatically. No single point of failure, no single point of overload.

Why Anycast Matters

Latency drops dramatically. Users connect to the nearest server in network terms, cutting response times from hundreds of milliseconds to tens. For DNS, this matters—every website visit starts with a DNS lookup.

Failover becomes invisible. When a server or data center fails, BGP withdraws the route. Traffic redirects to the next-closest location within seconds. No load balancer reconfiguration. No DNS TTL delays. The network heals itself.

Scale becomes simple. Adding capacity means deploying servers that announce the same IP. Clients need zero updates. The network incorporates new nodes automatically.

DDoS attacks spread thin. Attack traffic distributes across the entire network rather than concentrating on one target. Terabit-scale attacks become manageable when absorbed by hundreds of endpoints simultaneously.

The Limitations

Stateful connections are hard. Anycast excels with stateless protocols like DNS over UDP. TCP is trickier—if network topology shifts mid-connection, your packets might route to a different server that knows nothing about your session. That server sends a TCP reset, breaking the connection.

For short-lived TCP connections, this rarely causes problems. Studies found session disruptions from routing changes in less than 0.017% of connections. But for long-running connections, it's a real constraint.

Route flapping disrupts sessions. When multiple anycast nodes are equidistant, minor routing changes can flip traffic between them repeatedly. Each flip potentially breaks stateful connections.

Cascading failures are possible. If one node becomes overwhelmed and withdraws its BGP announcement, traffic shifts to the next-closest node. If that node also lacks capacity, it can fail too—dominoes falling.

No Special Address Range

Unlike multicast (224.0.0.0/4) or private addresses (192.168.0.0/16), anycast has no reserved IP range. Any publicly routable address can be anycast.

The difference is purely routing configuration. Announce 8.8.8.8 from one location: unicast. Announce it from 50 locations: anycast. The IP address doesn't change. The routing behavior changes based on how many places announce it.

A packet sent to 8.8.8.8 looks identical whether it's reaching one server or one of hundreds. Anycast is invisible at the IP layer—it exists only in the routing infrastructure.

The Design Philosophy

Anycast reveals something about how the Internet was built.

The designers didn't try to create a system that knew the right answer to every routing question. They created a system where millions of routers, each with partial information, collectively discover good-enough answers through continuous negotiation.

Anycast leans into this. It doesn't fight the network's distributed nature—it exploits it. One address, announced from everywhere, and the network's collective intelligence routes traffic appropriately.

For services that must never fail, this trade-off works. DNS root servers can't afford single points of failure. CDNs need users reaching nearby caches. DDoS protection requires distributing attack traffic globally.

Anycast solves all three with one mechanism: trust the network to figure it out.

Sources