← Learn··Updated 21 May 2026·3 min read

What is anycast?

A short reference on anycast — one IP address announced from many locations, how routing picks the nearest one, why CDNs and DNS root servers use it, and where the edge cases bite.

Networking
#networking
#anycast
#bgp
#cdn

The one-line definition

Anycast is a routing technique where the same IP address is announced from multiple physical locations, and the network delivers any given packet to whichever location is "closest" by the routing protocol's metric — usually BGP path length.

One address, many hosts, automatic geo-distribution baked into the layer-3 routing fabric. No application code knows that the destination is in more than one place.

How it actually works

Imagine an IP 192.0.2.1 announced via BGP from three locations:

flowchart TD
    Client((Client in Tallinn))
    P1["PoP 1: Frankfurt<br/>192.0.2.1"]
    P2["PoP 2: Singapore<br/>192.0.2.1"]
    P3["PoP 3: São Paulo<br/>192.0.2.1"]
    Client -- BGP picks shortest path --> P1
    P2 -.->|further by BGP| Client
    P3 -.->|further by BGP| Client

A user in Tallinn sends a packet to 192.0.2.1. The internet's routing tables — which the user's ISP and every transit network between them participate in — collectively say "the best path to 192.0.2.1 goes via Frankfurt." The packet flows to Frankfurt. A user in Tokyo sending to the same address gets routed to Singapore. No DNS trickery, no client-side logic.

The "best path" is whatever BGP decides. Usually that correlates with shortest AS-path or lowest latency, but BGP is a policy protocol — operators can prefer one PoP over another for business reasons, and the picked path is not always the geographically closest one.

Where you encounter it

  • The DNS root servers. Each of the 13 logical root server letters (a.root-servers.net through m.root-servers.net) is anycasted from hundreds of physical locations worldwide. When your recursive resolver queries a.root-servers.net, it reaches the closest instance — which is why root server queries are fast everywhere.
  • Public DNS. Cloudflare's 1.1.1.1 and Google's 8.8.8.8 are anycasted; the same IP serves you from a PoP near you.
  • CDNs. Cloudflare, Fastly, AWS CloudFront, and the others use anycast to absorb traffic at the network edge. The CDN announces a small set of IPs from every PoP; the routing fabric picks the closest one.
  • Time servers. pool.ntp.org plus several large NTP providers use anycast.
  • DDoS absorption services. Spreading the attack across many PoPs is much easier than concentrating it at one origin.

The edge cases

Anycast is not a free abstraction:

  • Stateful protocols can break. If routing flips mid-connection from one PoP to another (e.g. because a BGP path goes away), the new PoP has no idea about the existing TCP state and will reset. Anycasting TCP/HTTP works in practice mostly because routing is stable on short timescales — minutes, not seconds — but the failure mode is real.
  • UDP-without-state-keeping is the ideal case. DNS works particularly well over anycast because each query is one packet out, one packet back, no session state to carry. That's why anycast caught on for DNS first.
  • Asymmetric routing. A packet may flow Tallinn → Frankfurt on the way in, and Tokyo → São Paulo on the way back if the source IP is also anycasted. Most providers use unicast source IPs to avoid this.
  • Debugging is awkward. When something is broken, the answer to "which server are you hitting?" is not in DNS — it's in BGP. Tools like mtr and traceroute are your only window into which PoP the packet actually reached.

Anycast vs round-robin DNS vs load balancers

Three things often get confused:

  • Round-robin DNS — the authoritative DNS server returns multiple A records and varies the order. The client picks one. Distribution is rough and per-client. Failover relies on the client retrying when one record fails.
  • Anycast — one IP, many physical servers, routing picks the closest. Distribution is per-packet, not per-client, and the client never knows.
  • Load balancer (unicast) — one IP, one front door, many back-end servers behind it. Distribution happens inside the LB. Doesn't help with geo-distribution unless you also use one of the above.

You can stack them: a global service typically uses anycast for geo-distribution + a load balancer at each PoP for distribution within a region.

A real example

The /tools/whats-my-ip tool runs on a single K3s cluster, so it is not anycasted — every visitor hits the same physical site. If you query 1.1.1.1 from a whats-my-ip-style tool on a Cloudflare-anycasted DNS resolver, the IP you see for the recursive resolver's perspective is the same 1.1.1.1, but the PoP you actually talked to is wherever BGP routed you. That's anycast working invisibly.