Anycast vs GeoDNS

Anycast: same IP, many places

An anycast address is an IP advertised from multiple physical locations simultaneously via BGP. Routers everywhere receive multiple paths to the same IP and pick the topologically closest one. From the user's perspective there is just one IP; under the hood, packets sent to that IP land at whichever POP is "closest" according to BGP's path-selection algorithm.

How the CDN sets it up:

1. The CDN owns a /24 (or larger) IPv4 block and a corresponding IPv6 block.
2. Every POP runs BGP routers that announce the prefix to upstream peers (Tier 1 ISPs, IXPs).
3. The same prefix gets announced from every POP simultaneously.
4. The global BGP routing table now has many paths to the same prefix; each AS picks the one with the shortest AS path (or the one that wins based on local preference).
5. When a user's packets reach the internet backbone, BGP routing automatically sends them to the topologically closest POP.

Routing happens at the network layer; the application sees nothing. A user in Frankfurt sending to 1.1.1.1 reaches the Frankfurt POP; a user in Tokyo reaches the Tokyo POP. They both connect to "1.1.1.1" — different servers respond.

GeoDNS: different IPs per region

GeoDNS handles routing at the DNS layer instead of the IP layer. The CDN runs an authoritative DNS server that returns different IPs based on where the requesting resolver is geolocated:

User in Tokyo asks resolver for cdn.example.com
  → resolver asks authoritative DNS
  → authoritative DNS sees resolver IP geolocates to Japan
  → returns 13.x.x.x (Tokyo POP IP)
User in Frankfurt asks resolver for cdn.example.com
  → resolver asks authoritative DNS
  → authoritative DNS sees resolver IP geolocates to Germany
  → returns 18.x.x.x (Frankfurt POP IP)

The IPs are different per region; routing to each is just standard unicast. The CDN's "intelligence" lives in the DNS response logic rather than in BGP announcements.

Side-by-side comparison

Why anycast often wins on raw performance

Anycast routes packets to the topologically closest POP — measured in BGP hops, not geographic distance. This is usually what you actually want because BGP path length correlates with network latency: short AS paths through major IXPs are fast; long paths through tier-2 networks are slow.

GeoDNS picks by geography, which is imperfect:

• A user in eastern Russia geographically is closer to Asian POPs but their internet traffic may route through Moscow → European peering → arriving at a European POP faster than the Asian one.
• Pacific Island and Caribbean users often have peering paths through one specific mainland connection — the geographically closest POP may not be the network-closest.
• Mobile users on roaming agreements can be geolocated to their home country even though they are physically elsewhere.

Anycast follows the actual network paths, not the geographic ones. Performance differences are usually small but consistent in anycast's favor.

The GeoDNS resolver problem

GeoDNS infers user location from the resolver IP, not the user IP. This breaks in three common scenarios:

Public DNS resolvers

A user in Tokyo using Google's 8.8.8.8 sees their query answered by whichever Google resolver instance is closest. If that resolver is in Singapore, GeoDNS infers Singapore and returns a Singapore POP IP — even though the user is in Tokyo.

EDNS Client Subnet (ECS), RFC 7871, mitigates this. Resolvers that support ECS forward a truncated form of the user's IP to authoritative servers, so GeoDNS can see the user's network even when behind a public resolver. Google, OpenDNS, Cloudflare, and Quad9 all support ECS. Some smaller resolvers and many private corporate resolvers do not.

Corporate VPNs and proxies

A user working from home via a corporate VPN tunnels DNS through the corporate resolver, which may be in the company's HQ region. GeoDNS sees the resolver region, returns that region's IP. The user's actual location is irrelevant.

Misgeolocated IP blocks

Geolocation databases (MaxMind, IP2Location) are estimates. Some IP blocks are mislabeled, especially for smaller carriers, mobile networks, and recently-allocated ranges. Errors propagate into GeoDNS routing.

Anycast's failure modes

Anycast is not without issues. Three real problems:

BGP convergence on POP failure

When a POP fails (or is intentionally drained), its BGP announcement is withdrawn. Routers around the internet must remove the failed path and converge on the next-best. This takes 30 seconds to several minutes during which packets to the affected IP either drop or are blackholed.

Mitigations: graceful BGP shutdown (signal withdrawal before actually going down), multi-prefix designs (advertise a backup prefix), and BFD (Bidirectional Forwarding Detection) for faster failure detection. The CDN's operational maturity matters here.

TCP connection survivability across rerouting

If BGP reroutes traffic mid-connection (the previously-shortest path becomes longer due to a peering change), the new POP receives packets for a connection it does not have state for. The packet is dropped; the user sees a connection error and retries to (potentially) the new POP.

This is rare but real. Long-lived connections (WebSocket, HTTP/2 sessions, streaming) are most affected. Mitigations exist (consistent hashing of source IP to a specific instance within each POP, sticky load balancing) but cannot eliminate the issue entirely.

Asymmetric routing

Anycast routes are advertised per-prefix. If your CDN advertises two prefixes (say, A for HTTPS and B for HTTP), BGP may route a single user's traffic for A and B to different POPs. For most use cases this is fine; for stateful per-IP rate limiting or analytics, it can be confusing.

The hybrid pattern

Many enterprise CDN setups combine anycast and GeoDNS:

1. GeoDNS returns a regional anycast pool: a /24 announced only within that region.
2. Within the region, anycast picks the best POP.

This combines GeoDNS's coarse regional selection (useful for legal compliance: ensure EU users land at EU POPs) with anycast's fine-grained network-aware routing. Akamai pioneered this approach; Google Cloud CDN uses a variant; Cloudflare's enterprise tiers offer per-region prefixes.

The DDoS dimension

Anycast dramatically improves DDoS resilience. An attacker generating 1 Tbps of attack traffic against an anycast IP sees the load distributed across every POP that announces the prefix — each POP only handles its share based on which users route to it. A 200-POP anycast network can absorb 1 Tbps as 5 Gbps per POP, well within each POP's capacity.

GeoDNS concentrates traffic on per-region IPs. The same 1 Tbps attack against a single region's IP overwhelms that one POP's capacity. To compensate, GeoDNS-based CDNs either provision much larger per-POP capacity or use specialized DDoS scrubbing infrastructure in front of origin.

This is why anycast has become the dominant approach for new CDNs over the past decade — the combination of routing efficiency and DDoS absorption is hard to beat with DNS-based approaches.

When GeoDNS is the right choice

Despite anycast's advantages, GeoDNS has legitimate uses:

• Mandatory regional segregation. Data residency requirements that mandate user data never traverses certain regions. Anycast cannot guarantee this; GeoDNS can.
• Stateful applications where connection persistence is critical. Long-lived TCP connections that cannot tolerate BGP rerouting. GeoDNS pins to a specific IP.
• Cost optimization across regions. Some regions cost more to serve from than others; GeoDNS can route users to cheaper regions when latency is not critical.
• A/B testing and feature flags by region. Different application versions per region without rebuilding the application's region logic.

Frequently Asked Questions

What is anycast routing?

Anycast is a network addressing technique where a single IP address is announced from multiple physical locations. BGP — the internet's routing protocol — picks the topologically closest location for each user based on AS path length and routing policies. The user has no idea their packets are reaching different servers based on their network location; they just see a single IP. CDNs like Cloudflare and Fastly use anycast to route users to the nearest POP automatically.

How does GeoDNS know where the user is?

GeoDNS infers user location from the IP of the DNS resolver that submitted the query, not the user's IP directly. The DNS server geolocates the resolver IP via a database like MaxMind and returns the appropriate per-region answer. This is approximate — a user in Tokyo using Google's 8.8.8.8 resolver appears to come from wherever the nearest Google resolver instance is. EDNS Client Subnet (ECS) optionally passes a truncated form of the user's IP through to authoritative servers to improve accuracy.

What is the failure mode of anycast?

BGP convergence. When a POP fails or is withdrawn, the BGP announcement disappears and routers worldwide must update their tables to use the next-best route. This typically takes 30 seconds to several minutes during which packets to the failed POP either drop or are blackholed. For TCP applications this manifests as connection failures; for UDP applications, packet loss. Multi-POP advertisements and graceful BGP shutdown procedures minimize the window but cannot eliminate it.

Why does my GeoDNS sometimes send me to the wrong region?

Three common causes: (1) your DNS resolver is in a different region than you are (using a remote DNS like a corporate proxy or VPN); (2) the geolocation database has stale data for your IP; (3) the authoritative DNS server does not support EDNS Client Subnet so it only sees the resolver IP. For applications with strict regional requirements, switch to anycast routing or run your own DNS resolver close to your users.

Can I combine anycast and GeoDNS?

Yes — and major CDNs often do. GeoDNS returns a regional anycast pool (different IPs per region). BGP within the region picks the closest POP within that pool. This combines GeoDNS's coarse-grained region selection with anycast's fine-grained intra-region routing. Common pattern at Akamai, Cloudflare's enterprise tiers, and Google Cloud CDN.