Anycast DNS: How One IP Serves Answers Worldwide

Anycast DNS is the technique that lets a single IP address live in many places at once, so that a query sent to 1.1.1.1 from Tokyo and the same query from London land on completely different physical servers, each one close to the person asking. It is how modern DNS providers deliver fast answers everywhere from one address, survive outages without changing a single record, and absorb denial-of-service attacks that would flatten a single machine. If your authoritative nameservers are anycast, you get global speed and resilience for free, without touching your zone.

Unicast vs anycast

In the ordinary internet, almost every IP address is unicast: one address, one destination. Routers across the world cooperate to deliver packets for that address to exactly one machine. Anycast changes one assumption. The same IP address, or more precisely the same IP prefix, is announced from many separate locations at the same time, and the routing system treats them as alternative paths to one destination.

The user does nothing different. They send a packet to one address. The network decides which copy of that address is closest and routes them there.

How BGP makes it work

The mechanism underneath anycast is BGP, the Border Gateway Protocol that stitches the internet's networks together. Every site that hosts a copy of the anycast service announces the same IP prefix to its upstream providers, usually from its own autonomous system. Routers everywhere then see many announcements for the same prefix and treat them as competing routes to the same place.

1. Each location runs a nameserver configured with the shared anycast IP.
2. Each location announces the same prefix into BGP from its network.
3. Routers across the internet collect these announcements as multiple paths to one destination.
4. Each router picks the best path by its own policy, which usually favors the shortest AS path, landing traffic at the topologically nearest site.
5. A query therefore reaches whichever copy is closest to the resolver that sent it.

Note the subtlety: "nearest" means nearest in network topology, not necessarily in physical miles. BGP optimizes for path length and policy, which usually correlates with proximity but not always. This is why anycast operators care deeply about where they peer and how their routes are seen.

Why DNS is a near-perfect fit

Anycast works best for traffic that is stateless and short, and DNS over UDP is exactly that. A typical DNS exchange is one small request and one small reply, with no session to maintain. If the routing table shifts mid-stream and the next query goes to a different site, nothing breaks, because each query stands alone.

Compare that with a long-lived TCP session such as a large file download. If anycast rerouting sent packets from the same connection to two different servers, the session would collapse because neither server holds the full state. DNS sidesteps that problem entirely, which is why anycast and authoritative DNS grew up together. The root servers, the big public resolvers, and essentially every serious managed DNS platform run on anycast.

The three big wins

• Lower latency. Because queries hit the nearest site, round-trip times drop. For DNS, which gates the very first step of loading anything, shaving milliseconds off resolution improves the felt speed of every site and app.
• Automatic failover. If a site goes down, it stops announcing the prefix, and within seconds BGP withdraws that route. Traffic shifts to the next-nearest site with no DNS change, no TTL wait, and no action from you. Your records never move.
• DDoS resilience. A flood of attack traffic is spread across every site that announces the address rather than concentrated on one machine. The capacity of the whole anycast network, not a single server, is what an attacker must overcome. Large providers deliberately over-provision sites for exactly this reason.

Seeing anycast in action

You cannot see anycast directly in a normal DNS answer, because the IP looks like any other IP. What you can observe is that the same address answers from different places with very different latencies, and that many providers embed a location hint you can query.

# Cloudflare's resolver reveals which datacenter answered:
$ dig CH TXT id.server @1.1.1.1 +short
"SJC"     # answered from San Jose

# Run the same query from a server in Europe and you may get:
"LHR"     # answered from London -- same IP, different site

# Google Public DNS exposes a similar hostname.bind style probe:
$ dig CH TXT hostname.bind @8.8.8.8 +short

The CH here is the CHAOS class, a special diagnostic class many servers use to report their own identity. Seeing two different cities answer the same anycast IP is anycast proving itself.

Trade-offs and caveats

• Operational complexity. Running anycast means running BGP in multiple locations with consistent configuration. This is why most people consume anycast through a provider rather than building it.
• Topology is not geography. A poorly peered site can draw traffic from farther away than expected. Good anycast depends on good interconnection, not just many locations.
• Route flaps. If BGP paths are unstable, queries can bounce between sites. For stateless DNS this is harmless, but it can complicate debugging because the server that answered may differ query to query.
• Not for long sessions. Anycast is ideal for DNS and other stateless request-response traffic, and is used carefully or avoided for stateful connections unless extra engineering keeps a client pinned to one site.

What it means for you

You almost never configure anycast yourself. Instead you choose a DNS provider whose authoritative network is anycast, and your domain inherits the benefits the moment you point your nameservers at it. When comparing providers, the questions worth asking are how many points of presence they run, how well those sites are peered, and how they handle failover and attack mitigation. The IP address in your delegation stays exactly the same; the magic is in how that one address is announced to the world.

Check how your domain resolves globally

The whole promise of anycast is that your domain answers quickly and consistently from everywhere, which is precisely the thing a single lookup from your own desk cannot confirm. After you move to an anycast provider or change nameservers, verify that your records resolve the same way across many regions with the Valla DNS propagation checker, and the Valla DNS /learn/ guides on DNS failover and TTL strategy explain how anycast complements the record-level redundancy you may already use.