Anycast Explained: One IP Address, Served From Everywhere

June 5, 2026 17 min read Networking Deep Dives

networkinganycastbgpdnscdnddos

Contents

The internet’s most heavily-used IP addresses — 1.1.1.1, 8.8.8.8, the thirteen DNS root server addresses — are each answered by hundreds of geographically dispersed machines simultaneously. If you send a DNS query to 1.1.1.1 from Tokyo, a Cloudflare server in Tokyo responds. If you send the same query from Frankfurt, a server in Frankfurt responds. Both machines use the exact same IP address. There is no DNS-based load balancing here, no NAT, no proxy redirect. The routing fabric of the internet itself is what decides which physical machine you reach — and it does so transparently, at line rate, using a technique called anycast.

Anycast is not a new protocol or a software layer you install. It is a deliberate abuse of BGP semantics: the same prefix is legitimately announced from multiple independent locations, and the internet’s normal shortest-path selection machinery routes each packet to whichever announcement it considers closest. Understanding how that works — and why it is both elegant and occasionally treacherous — requires a detour through the four fundamental IP addressing models.

The Four Addressing Models

Every IP packet is addressed according to one of four delivery semantics. Three are familiar from everyday networking; anycast is the odd one that most engineers rarely think about explicitly.

Model	Addressing	Delivery	Typical Use
Unicast	One sender → one specific receiver	Delivered to exactly one host	HTTP, SSH, SMTP — almost everything
Broadcast	One sender → all receivers on a segment	Delivered to every host on the L2 domain	ARP, DHCP discovery, NetBIOS
Multicast	One sender → a subscribed group	Delivered to all group members	IPTV, routing protocol updates (OSPF, PIM)
Anycast	One sender → the nearest of a group	Delivered to exactly one of many equivalent receivers	DNS resolvers, CDN, NTP, DDoS scrubbing

The key distinction is the word nearest. In unicast, the IP address identifies a unique host. In anycast, the IP address identifies a service role — and the network’s job is to pick the topologically nearest instance of that role to serve the request. The sender has no idea (and in most cases does not care) which physical host responds. They just want an answer.

How BGP Anycast Actually Works

To understand the mechanics, you need a firm grip on how BGP builds the internet’s routing table. If you need a refresher on BGP fundamentals — autonomous systems, eBGP vs iBGP, path attributes — see the BGP fundamentals guide.

The Same Prefix Announced Everywhere

In a unicast deployment, a company that owns the prefix 203.0.113.0/24 will originate that prefix into BGP from one location — typically from their own AS or from their upstream ISP. The prefix propagates across the internet, and every router in the world eventually has a single best path to it.

In an anycast deployment, the operator announces the same prefix from multiple physical locations, each using the same origin AS. There is nothing special in the BGP announcement itself — it is an ordinary NETWORK statement or aggregate route originated into BGP at each PoP. The routing table of an internet core router might look like this after convergence:

Router in Chicago, routing table entry for 203.0.113.0/24:
  via AS 12345 → PoP Chicago (AS-PATH: 12345)         [best]
  via AS 7018 → AS 12345 → PoP New York (AS-PATH: 7018 12345)
  via AS 3356 → AS 12345 → PoP Los Angeles (AS-PATH: 3356 12345)
  via AS 1299 → AS 12345 → PoP Frankfurt (AS-PATH: 1299 12345)

The Chicago router selects the Chicago PoP because it has the shortest AS-PATH. A router in London would see the Frankfurt announcement with fewer hops and select that instead. Route selection follows the standard BGP decision process — LOCAL_PREF first, then AS-PATH length, then MED, then IGP metric to the next-hop, and so on — with no anycast-specific modification to the protocol.

Topology, Not Geography

A subtlety that trips people up: anycast routes to the topologically nearest instance, not necessarily the geographically nearest one. Topology is determined by BGP path selection, which reflects peering relationships, link costs, and routing policy — not straight-line kilometers. A user in Seattle might be routed to a Los Angeles PoP if the Chicago PoP’s BGP path has more AS hops, or if Seattle has better peering with the LA announcement’s upstream. In a well-designed deployment this usually correlates with geography, but never assume it does.

The ASCII View

         ┌──────────────────────────────────────────────────────────┐
         │              Internet Routing Fabric (BGP)               │
         └──────────────────────────────────────────────────────────┘
                  ↑                    ↑                   ↑
    announces 203.0.113.0/24   announces 203.0.113.0/24  announces 203.0.113.0/24
                  │                    │                   │
         ┌────────┴──────┐    ┌────────┴──────┐   ┌───────┴───────┐
         │  PoP: Tokyo   │    │  PoP: Frankfurt│   │  PoP: Ashburn │
         │ 203.0.113.1   │    │ 203.0.113.1   │   │ 203.0.113.1   │
         └───────────────┘    └───────────────┘   └───────────────┘
                ↑                    ↑                    ↑
         User in Tokyo        User in Berlin        User in Virginia
         → routed to Tokyo    → routed to Frankfurt → routed to Ashburn
         (same dst IP)        (same dst IP)          (same dst IP)

Every user is sending packets to 203.0.113.1. BGP’s shortest-path selection delivers them to the closest announced instance. The users are completely unaware that different physical machines answered their requests.

Real-World Users of Anycast

DNS Root Servers

The DNS root server system is the canonical example. There are 13 named root server authorities (A-root through M-root), each with a single IPv4 and IPv6 address. As of early 2026, those 13 addresses are served by approximately 1,950 physical instances distributed globally across all populated continents. Without anycast, every DNS resolver on earth would have to reach one of 13 machines — a catastrophic single-point scenario. With anycast, any root query is absorbed by a nearby instance, and the failure of an entire continent’s worth of instances would not disrupt a user on the other side of the world.

The F-Root (operated by ISC) has instances in over 70 countries. Cloudflare operates additional F-Root instances under contract with ISC — their global network of 330+ cities effectively extends the root server footprint.

Public Recursive Resolvers

Cloudflare’s 1.1.1.1 and 1.0.0.1, and Google’s 8.8.8.8 and 8.8.4.4, are both anycast addresses. When you configure your laptop to use 1.1.1.1, you are not talking to a single machine. You are sending UDP packets to an anycast address that is announced from Cloudflare’s entire global network. The response comes from whichever Cloudflare PoP your ISP has the best BGP path to. This is why query latency to 1.1.1.1 is typically under 5ms in major cities worldwide.

DNS is the perfect anycast workload: each query-response exchange is a single UDP datagram pair. There is no connection state, no session to maintain, no handshake to interrupt if the route changes. The server that sees your query packets just answers them.

For more on how DNS resolution works as a whole — from your stub resolver through to authoritative servers — see the DNS deep dive.

CDNs and Edge Networks

Content delivery networks use anycast extensively, both for DNS (so that lookups for CDN-hosted domains resolve quickly) and increasingly for direct HTTP/HTTPS traffic delivery. Cloudflare, Fastly, and AWS CloudFront all rely on anycast to route end-user requests to the nearest edge PoP. This is exactly the architecture described in the Cloudflare Workers and edge-compute post — a globally distributed compute layer reachable via a single set of anycast-announced IP ranges.

NTP

Network Time Protocol shares DNS’s stateless request-response pattern. Large-scale NTP deployments — including enterprise deployments and some public pool infrastructure — use anycast to distribute time clients to the nearest stratum-1 or stratum-2 source. The NTP Pool Project supports anycast prefix announcements for networks willing to participate in distributing their anycast addresses. The client simply sends a UDP request to an anycast address; the nearest instance responds with a timestamp.

Why Anycast Is Perfect for DNS (and Historically Tricky for TCP)

The Stateless Sweet Spot

Protocols that are stateless or use very short-lived sessions map cleanly onto anycast. DNS over UDP is the textbook case. Each query is independent. If two consecutive queries from the same client happen to reach two different PoPs (because BGP route selection flickered between announcements), it does not matter — both PoPs can answer independently. There is no state to synchronize between PoPs, no connection teardown required.

This is why anycast works so naturally for DNS, NTP, and simple UDP-based protocols, and why the internet’s most resilient infrastructure has used it for decades.

The TCP Concern: Route Flap

The historically cited concern with anycast and TCP is route flap. A long-lived TCP connection maintains sequence numbers, window state, and congestion control variables. All of that state lives on one specific server. If a BGP route change mid-connection causes subsequent packets to be delivered to a different physical server — which has no knowledge of the existing TCP session — those packets will be RST’d or silently dropped. From the client’s perspective, the connection is severed unexpectedly.

In theory, this concern is valid. In practice, modern anycast deployments serving TCP handle it well for several reasons:

BGP route stability. Well-engineered PoPs with redundant upstreams do not flap. A BGP session withdrawing a route is typically a deliberate operational act (taking a PoP offline) or a genuine upstream failure — not a random mid-session hiccup. For a connection lasting a few hundred milliseconds (a typical HTTPS TLS handshake + request + response), the probability of a route change is extremely low.

Short connection durations. The overwhelming majority of HTTP/HTTPS connections in CDN traffic are short: a TLS session that completes in under a second. HTTP/2 and HTTP/3 push toward longer-lived connections but with request multiplexing, so even if a route change terminates the TCP session, the user perceives a brief reconnect rather than lost data.

QUIC. QUIC’s connection ID mechanism decouples the connection identity from the 4-tuple (src IP, src port, dst IP, dst port). A QUIC connection can survive IP address changes on the client side. While QUIC does not inherently solve the server-side anycast problem, CDN implementations pair QUIC with consistent hashing at the edge to achieve genuine connection migration. See the QUIC and HTTP/3 deep dive for a full treatment of QUIC.

Consistent hashing within a PoP. A large anycast PoP typically consists of many individual servers behind an L4 load balancer. Consistent hashing on the 5-tuple ensures the same client always reaches the same backend within a PoP, so even if the routing brings that client to the right PoP, they reach the right machine. Compare this with the more general load-balancing strategies discussed in the load-balancing guide.

The bottom line: Cloudflare, Fastly, and Akamai collectively terminate billions of TCP and QUIC connections over anycast every day. The “TCP doesn’t work over anycast” concern is a historical caveat, not a current limitation, when the deployment is engineered properly.

DDoS Mitigation via Anycast

Anycast provides a structural defense against volumetric DDoS attacks that scrubbing-center architectures struggle to match.

The Problem with Unicast Under Attack

In a conventional unicast deployment, your service is reachable at a single IP address anchored to one location (or a small number of locations). A volumetric DDoS attack — a botnet flooding your IP with 1 Tbps of UDP traffic — arrives at one place. You either absorb it locally (expensive, may saturate upstream pipes) or null-route the target IP (you’ve just DDoS’d yourself). Scrubbing centers help but introduce latency and require traffic diversion.

How Anycast Distributes the Load

With anycast, a 1 Tbps attack aimed at your IP address is not 1 Tbps arriving at one location. BGP routing will distribute the botnet’s traffic across all your PoPs proportionally to how many botnet members have each PoP as their closest announcement. A botnet distributed across 100 countries might spread 1 Tbps across 30 PoPs, with each PoP absorbing 30–50 Gbps — a load that large network operators handle routinely with inline hardware filtering.

Botnet distributed globally (100,000 hosts):
                         ↓
         ┌───────────────────────────────────┐
         │     Anycast IP: 203.0.113.1       │
         └───────────────────────────────────┘
              ↓             ↓            ↓
    PoP Frankfurt      PoP Singapore   PoP Ashburn
    (~320 Gbps)        (~280 Gbps)     (~400 Gbps)
    inline scrub       inline scrub    inline scrub
    → 200 Gbps          → 180 Gbps    → 250 Gbps
      dropped             dropped        dropped

This is precisely why Cloudflare, Akamai, and Imperva offer anycast-based DDoS mitigation as a primary service. Their combined network capacity across all PoPs dwarfs any realistic attack volume, and anycast ensures no single location becomes the chokepoint.

There is an important caveat: anycast DDoS defense only works when the attacker’s botnet is globally distributed. A highly concentrated attack from a single region may still saturate a PoP. Well-designed anycast networks include per-PoP capacity planning and the ability to null-route at the PoP level while keeping other PoPs serving legitimate traffic.

Operational Realities

Which PoP Am I Actually Hitting?

This is the first question every operator asks when debugging. BGP’s routing decisions are not visible from within a connection. Several mechanisms exist to identify the responding PoP:

DNS NSID (RFC 5001). Most anycast DNS deployments support the NSID EDNS0 extension. The query includes an NSID option, and the responding server returns an identifier — usually a string like ams01.cloudflare-dns.com or a short location code. Query it with dig:

1

dig +nsid @1.1.1.1 . SOA +norec +noall +comments

The response ; NSID: ... field identifies the specific instance that answered.

CHAOS class queries. Many anycast DNS servers respond to CHAOS TXT queries that reveal their node identity:

1
2
3
4
5


dig @f.root-servers.net hostname.bind txt ch +short
# Returns something like: "lga1a.f.root-servers.org"

dig @8.8.8.8 o-o.myaddr.l.google.com TXT +short
# Returns your IP as seen from the Google PoP

Traceroute. A plain traceroute to an anycast address will show you the path to one specific instance. Run it from multiple vantage points (or use a looking-glass service) and you will see different exit points:

1
2


traceroute -n 1.1.1.1
# Watch where the hops converge — the final few hops reveal the PoP

RIPE Atlas and looking glasses. For systematic PoP mapping, RIPE Atlas probes distributed worldwide can simultaneously traceroute to the same anycast address. The diverging paths reveal which PoPs each region is hitting.

Withdrawing a Sick PoP

One of anycast’s most powerful operational properties is the ability to gracefully remove a broken PoP from service. Since traffic reaches a PoP only because that PoP is announcing the anycast prefix, stopping the BGP announcement redirects all traffic to other PoPs within BGP convergence time (typically seconds to minutes, depending on upstream timer configurations).

A typical workflow using FRRouting:

1
2
3
4
5
6
7
8


# On the sick PoP's router — withdraw the anycast prefix
vtysh -c "configure terminal" \
      -c "router bgp 12345" \
      -c "no network 203.0.113.0/24" \
      -c "end"

# Verify the prefix is withdrawn from peers
vtysh -c "show bgp ipv4 unicast 203.0.113.0/24"

Once the announcement is withdrawn, BGP propagation removes this PoP from the internet’s routing table and traffic naturally flows to the next-best PoP. No DNS TTL to wait for, no sticky sessions to drain — just BGP convergence.

A more graceful approach uses BGP communities to signal reduced preference before a full withdrawal — prepending your own ASN multiple times to make the path artificially longer, gradually shifting traffic away while the PoP is still functional.

Traffic Engineering Without Determinism

Anycast makes traffic engineering harder than unicast. In a unicast setup, you control exactly where traffic lands. In anycast, BGP’s best-path selection determines which users reach which PoP, and you can only influence this indirectly:

AS-PATH prepending lengthens the path to a specific PoP, pushing users to other PoPs.
BGP communities sent to upstream peers can influence LOCAL_PREF at peers that honor them, effectively changing route preference for subsets of the internet.
Selective announcement scope — announcing a more-specific prefix (e.g., a /25) from one PoP alongside the broader /24 from all PoPs allows a subset of the address space to be routed exclusively to one location.

None of these tools give you the precision of a unicast setup. Predicting exactly which PoP a given user will hit requires active measurement, not configuration.

The Real Trade-offs

Anycast is genuinely powerful, but it comes with real costs that should not be papered over.

You need your own AS and address space. Running anycast on the public internet requires a public ASN (obtained from ARIN, RIPE NCC, APNIC, or another RIR) and provider-independent IP space that you can announce from multiple upstreams. If you are renting IP space from a single ISP, that ISP’s routes own your prefix and you cannot announce it from a different location. The minimum prefix size for reliable global routing is a /24 for IPv4 (shorter prefixes are routinely filtered by upstream ASes). This is a meaningful barrier to entry for small operators.

The alternative is using an anycast-as-a-service provider (Cloudflare Magic Transit, Fastly Anycast, etc.) that announces your prefix from their PoPs on your behalf, but then you are dependent on their network and their BGP policy.

Debugging is harder. Bugs in anycast deployments can produce maddening symptoms. A misconfigured PoP may serve some percentage of users incorrectly while others are unaffected — because different users are routed to different PoPs. Reproducing an issue may require knowing and replicating the BGP path to the affected PoP. The tools described above (NSID, CHAOS queries, traceroute) help, but debugging anycast requires operational discipline that unicast deployments do not.

Non-deterministic user routing. You cannot guarantee that a user will hit a specific PoP. This matters for stateful workloads — if you absolutely need request affinity, anycast alone is not sufficient and must be paired with consistent hashing or session tokens. It also means capacity planning must account for uneven traffic distribution; BGP topology can concentrate surprising fractions of traffic at specific PoPs.

BGP convergence time is not zero. When a PoP goes down or its BGP sessions drop unexpectedly (as opposed to a graceful withdrawal), convergence takes time. During that window, some users may experience packet loss or failed connections while routers across the internet update their routing tables. Route dampening at upstream providers can extend convergence time. Good anycast deployments pair BGP with health checking that triggers graceful withdrawals before a PoP fully fails.

IPv6 considerations. Anycast works identically for IPv6, but /48 and /32 prefix sizes for IPv6 anycast require similar provider-independent space. The IPv6 routing table is less filtered than IPv4’s, but the same principle applies: you need space you can announce from multiple locations independently. See the IPv6 basics primer for background on IPv6 address allocation.

Verdict

Anycast is the correct architecture for any service that must be globally reachable with low latency, high resilience, and structural DDoS resistance. The internet’s DNS infrastructure runs on it because there is no better option: 1,950 root server instances under 13 IP addresses, converged by BGP, invisible to clients. Public resolvers, CDN edge networks, and NTP deployments follow the same pattern for the same reasons.

For stateless UDP protocols, anycast is essentially the ideal distribution mechanism — no state, no sessions, no synchronization required. For TCP and QUIC, modern deployments have made anycast completely viable through route stability, consistent hashing, and short connection durations. The old “TCP doesn’t work over anycast” concern has been operationally disproved at massive scale.

The honest costs are the barrier to entry (your own ASN and address space), the loss of deterministic routing control, and the increased debugging complexity. If you are operating infrastructure where “route the user to the nearest healthy instance automatically” is a first-class requirement, anycast delivers that more reliably and more efficiently than DNS-based geolocation, GeoDNS round-robin, or global load-balancer steering. It is the routing fabric doing its actual job.