You send a DNS query to 8.8.8.8 from Lisbon. Someone in Tokyo uses the same address. Both can reach Google’s DNS service through different locations, without choosing a regional server or changing that familiar string of numbers.
The address stays the same. The place answering can change.
This is anycast, an addressing and routing technique that makes one service IP address available at multiple network locations. Packets sent to that address are routed to one available instance according to the routing system’s decisions.
An IP address often feels like a street address. With anycast, it can act more like the identity of a service with many entrances.
How does anycast work?
Imagine a fictional DNS service operating in Lisbon, Chicago, and Singapore. Each site makes the same service address available: 203.0.113.53. This example address comes from a range reserved for documentation; it is not a live service to test.
At Internet scale, a simplified deployment works like this:
- The operator deploys a service instance at each location and arranges for the shared address to reach the local service.
- Each location advertises reachability for an IP prefix containing that address through Border Gateway Protocol (BGP).
- Networks learn and select routes according to their routing policies and the available paths.
- Routers forward a client’s packets toward the selected location using ordinary IP forwarding.
BGP exchanges network reachability information, including prefixes and path attributes. It helps populate routing information; it does not place a complete itinerary into every packet.
The client can keep using the same destination IP. There is no special anycast packet header to add, and the address itself looks like an ordinary unicast address. Global anycast works with both IPv4 and IPv6. Operators can also deploy anycast inside their own networks using interior routing protocols rather than global BGP.
RFC 4786 describes the operational model. Anycast is a technique built on routing, rather than a separate transport protocol.
“Nearest” means nearest according to routing
Anycast is often described as sending traffic to the nearest server. That wording needs care.
Internet routing considers policies, connectivity, and path attributes. BGP does not automatically compare the current response time of every service instance and choose the fastest one. The selected route can lead to a site farther away geographically, and two Internet providers in the same city can select different sites.
Operators can influence these choices through peering and traffic engineering. They cannot turn the whole Internet into a single perfectly coordinated latency-based scheduler.
The set of clients reaching a site is its catchment. Catchments follow routing and can shift when routes change; they are not fixed circles around data centers.
Anycast vs. unicast, multicast, and broadcast
These terms describe different delivery patterns:
| Method | Where a packet is intended to go | A useful way to picture it |
|---|---|---|
| Unicast | One individually addressed destination | Deliver to this endpoint |
| Anycast | One member of a set sharing an address, selected through routing | Deliver to one suitable entrance |
| Multicast | Members of a destination group, within the applicable scope | Deliver to the subscribed group |
| Broadcast | All hosts within the relevant broadcast scope | Deliver throughout this local scope |
Anycast does not intentionally replicate a client’s packet to every service location. Its useful shorthand is one-to-one-of-many.
IPv6 formally defines unicast, anycast, and multicast addressing, and uses multicast in place of broadcast. Its anycast addresses come from the unicast address space; RFC 4291 explains the distinction.
Why DNS is such a good example
A DNS server can answer a short query without requiring the client to maintain a long conversation with that particular machine. That makes many DNS transactions a useful fit for distributed service instances, although DNS also uses TCP and encrypted, connection-based transports.
Google Public DNS documents its use of anycast: queries to addresses such as 8.8.8.8 are directed toward a location advertising that address. The same number can therefore serve users around the world through different entry points.
There is another revealing example beneath everyday browsing. The DNS root system has 13 named server identities, but it is implemented through many instances distributed around the world. The root server operators’ FAQ explains how anycast helps make this possible. Thirteen names do not mean thirteen physical machines.
Anycast also differs from DNS-based traffic steering. DNS steering can give clients different destination addresses. Anycast can keep the destination address unchanged while routing selects its location. A provider can combine both techniques.
What happens when a site fails?
If a service instance fails, its operator can withdraw the relevant route or redirect traffic to a working instance. Affected traffic can use another available path after routing converges.
That coordination matters: a crashed DNS process does not necessarily remove its network route. A reachable router can still lead to a broken service.
Anycast also does not synchronize databases, DNS zone data, or application state. The operator must make the service instances sufficiently consistent for the application. RFC 3258 discusses this coordination for distributed authoritative DNS servers. Distribution creates resilience only when the surrounding system supports it.
Can anycast carry TCP and web traffic?
Yes, with appropriate engineering. Many content delivery networks and application delivery systems use anycast as an entry mechanism.
The challenge is connection state. If packets from an established TCP connection start arriving at another instance, that instance might know nothing about the connection. The result can be a reset or an interruption. RFC 7094 discusses these transport implications.
Providers address this with their routing and connection-handling architecture. For example, AWS Global Accelerator terminates client TCP connections at edge locations and establishes separate connections toward application endpoints. Its standard accelerators add endpoint health checks and controls for directing new connections.
That extra machinery matters: reaching another location at the same IP address does not, by itself, transfer an existing session there.
What anycast improves—and what still needs engineering
Anycast can help distribute demand, place service entrances closer to users in network terms, and provide alternative locations when a path becomes unavailable. These are useful building blocks for network scalability.
It can also spread traffic from a distributed denial-of-service attack across locations. Cloudflare describes this role in its anycast network, alongside traffic filtering and sufficient capacity.
Three limitations are worth remembering:
- Traffic is not necessarily balanced evenly. Routing catchments can send much more demand to one site than another.
- An address is not a geographic guarantee. Geolocation or a single traceroute does not establish where every client will reach the service.
- Capacity still matters. A distributed network can still have overloaded sites, saturated links, or shared dependencies that fail.
Simply assigning the same address to two ordinary computers on a home LAN does not create this coordinated architecture. Address management, service deployment, and routing all have to agree.
Anycast changes what a familiar IP address can represent: a service available through many doors. Your packet needs one entrance; the network’s routes determine which one it reaches.