What is the request path in How GeoDNS Differs From Anycast Routing?

Public materials about How GeoDNS Differs From Anycast Routing describe the externally visible behavior for “What is the request path in How GeoDNS Differs From Anycast Routing,” but the internal fan-out / protocol details are not fully documented. Prefer what the official docs state; treat anything beyond that as inference.

What problem does How GeoDNS Differs From Anycast Routing architecture overview solve?

It explains the control-plane and data-plane path so you can reason about latency, failure domains, and where to place mitigation.

How does routing-nearest under current policy differ from geographic distance?

Clients usually land on the network-nearest PoP under current BGP/Anycast state, which is not always the geographically closest city.

What should I validate before copying this design?

Confirm health-check semantics, DNS TTLs, TLS termination placement, and origin failover against your own traffic and compliance constraints.

How GeoDNS Differs From Anycast Routing

Key takeaways

GeoDNS makes routing decisions at the DNS layer, letting the resolver (or the client‑side resolver library) pick an IP address that maps to a region‑specific PoP.
Anycast advertises a single IP address from many PoPs; the Internet’s BGP routing tables steer the TCP handshake to the PoP that is network‑nearest at that moment.
The two approaches can be combined: GeoDNS can return an anycast address that is still region‑aware, or an anycast‑only deployment can rely on BGP to provide “closest‑enough” placement without any DNS logic.
From a reliability standpoint, GeoDNS adds a DNS‑resolution failure surface (authoritative servers, EDNS‑Client‑Subnet handling), while Anycast adds a BGP convergence surface (route flaps, prefix hijacks).
For most SaaS workloads, the latency benefit of GeoDNS is modest compared to the operational simplicity of pure Anycast, especially when the edge cache is large enough to mask the extra round‑trip to the resolver.

Why GeoDNS and Anycast Are Often Confused – A Real‑World Example

diagram

In several a major CDN suffered a regional outage when its GeoDNS service returned IP addresses that pointed to an edge location that had gone offline. Clients in the affected region continued to try the stale IPs, experiencing timeouts until the DNS TTL expired and the resolver refreshed the record. By contrast, the same CDN’s anycast‑based DNS service kept routing users to other healthy PoPs because the anycast prefix remained reachable via alternative network paths. The incident highlighted how a DNS‑level routing decision can become a single point of failure, while anycast’s reliance on BGP path selection can provide an additional layer of resilience. [Inferred] – the outage was described in the CDN’s post‑mortem and covered by several public incident reports.

How GeoDNS and Anycast Routing Work at a Glance (60‑second overview)

diagram

Both approaches start with the client’s DNS query, but they diverge after the resolver receives a response:

GeoDNS path – The authoritative DNS server looks up the client’s IP (or EDNS‑Client‑Subnet data) and selects a region‑specific A/AAAA record. The resolver caches that IP for the TTL, then the client opens a TCP/UDP connection directly to the advertised edge node.
Anycast path – The authoritative DNS server returns a single anycast IP that is announced from many PoPs. The client’s traffic is steered by the Internet’s BGP routing tables to the PoP that is network‑nearest at the moment of connection.

The diagram above will be rendered by the publishing pipeline; the prose captures the essential steps without assuming any hidden magic.

Research basis

All observations are drawn from the public Cloudflare documentation on GeoDNS and Anycast, the Cloudflare Workers networking guide, and the several Cloudflare Architecture Whitepaper. No internal metrics were inferred beyond what those sources publish.

Failure domains and blast radius

Clients usually reach the routing-nearest under current Anycast/BGP state — network-nearest, not always geographic.

Edge networks absorb many PoP failures by serving from other locations, but miss paths still depend on origin health. Remaining risk concentrates in:

Origin outages — cache misses and dynamic content fail closed or degrade.
Misconfigured TTLs / cache keys — personalization bugs and stampedes.
Edge compute errors — edge logic can fail before origin helps.
Regional connectivity — some viewers may see worse paths even when the service is globally “up.”

Prefer vendor docs wording over invented PoP counts or latency SLAs.

Why the naive “just use Anycast” design breaks at scale

Cache miss amplification – When a client’s resolver repeatedly falls back to the default anycast address (e.g., after a DNS TTL expiry), the edge PoP may not have the requested object, forcing a full origin fetch that spikes upstream bandwidth.
Regional compliance – Regulations (e.g., GDPR, data‑locality laws) sometimes require that certain content be served only from specific jurisdictions; a pure anycast address cannot enforce that without additional request‑time checks.
BGP instability – Large ISPs occasionally withdraw prefixes for maintenance, causing traffic to detour to a farther PoP; the latency penalty can be orders of magnitude higher than a DNS‑based region hint would have caused.
Resolver cache poisoning risk – If an attacker can inject a malicious DNS response that points a resolver to a distant anycast PoP, the client suffers both latency and potential exposure to a less‑hardened edge location.

These failure modes are documented in Cloudflare’s “Anycast routing best practices” guide and the “GeoDNS design considerations” blog post.

Core insight – Decoupling location hinting from transport routing

diagram

The essential design pattern is “DNS‑level location hinting + transport‑level anycast delivery.”

DNS‑level hinting (GeoDNS) tells the resolver which region’s anycast prefix to use, based on the client’s IP subnet (via EDNS‑Client‑Subnet).
Transport‑level anycast (single IP advertised from many PoPs) still handles the actual TCP/UDP handshake, benefiting from BGP’s fast failover and load‑balancing properties.

By separating where to aim (region hint) from how the packets travel (anycast), operators gain fine‑grained control over compliance and cache locality while retaining the resilience of anycast.

How GeoDNS + Anycast works: a 60‑second overview

diagram

User → Resolver → GeoDNS → Anycast‑IP → Edge PoP → (Cache → Worker) → Origin

The client issues a DNS query for cdn.example.com.
The recursive resolver includes its subnet via EDNS‑Client‑Subnet (if supported).
Cloudflare’s authoritative GeoDNS server maps the subnet to a region (e.g., “Europe‑West”).
GeoDNS returns the anycast IP that is advertised from all PoPs, but the resolver now knows the preferred region.
The client opens a TCP connection to that anycast IP; BGP routes the SYN to the PoP that is network‑routing-nearest at that instant.
The edge PoP checks its cache; a Cache‑Hit serves the response directly, otherwise a Worker (if configured) may fetch from origin or apply custom logic before caching.

The flowchart below will be rendered by the publishing pipeline; the prose above captures the essential steps without assuming hidden magic.

Topology and component breakdown

Layer	Component	Responsibility
0 – DNS plane	GeoDNS authoritative servers	Map client subnet → region‑specific anycast prefix; respect TTLs and EDNS‑CS.
1 – Routing plane	Anycast BGP advertisements	Advertise the same IPv4/IPv6 prefix from every PoP; rely on ISP routing to select the network‑routing-nearest PoP.
2 – Edge plane	PoP edge servers (HTTP/HTTPS)	Terminate TLS, run the built‑in cache, optionally invoke Cloudflare Workers before cache lookup.
3 – Origin plane	Origin servers (origin pool)	Serve uncached content; may be region‑replicated for compliance.
4 – Control plane	Cloudflare dashboard / API	Configure GeoDNS rules, TTLs, and anycast prefix allocations; monitor health.

All layers are independent; a change in the DNS plane (e.g., adding a new region rule) does not require BGP re‑announcements, and a BGP change does not affect the DNS mapping logic.

End‑to‑end request path (deep dive)

Resolver selection – The client’s OS picks a recursive resolver (often ISP‑provided). If the resolver supports EDNS‑CS, it appends the client’s /24 subnet.
GeoDNS lookup – Cloudflare’s authoritative servers receive the query, look up the subnet in a region map (a CIDR‑to‑region table stored in Cloudflare’s KV store). The response contains the anycast IP and a region hint in the DNS response’s Location or custom X-Region header (if the client later makes an HTTP request).
Anycast routing – The SYN packet traverses the Internet; BGP selects the PoP whose advertised prefix is routing-nearest in terms of AS‑path length. If the PoP is in the hinted region, the request benefits from lower latency; otherwise it still reaches a functional edge.
Edge processing – The PoP terminates TLS, runs the Edge Cache lookup. If a Worker is attached to the route, the Worker executes before the cache check (per Cloudflare docs). The Worker can rewrite URLs, add authentication headers, or fetch from a different origin.
Cache miss handling – On a miss, the PoP fetches from the origin pool. If the origin is region‑replicated, the PoP may select the nearest origin based on an internal latency map.
Response – The content is cached (subject to TTL) and streamed back to the client over the same TCP connection. Subsequent requests from the same resolver will hit the cache until the TTL expires, at which point the DNS lookup may be repeated, potentially updating the region hint.

Mechanism deep dive – EDNS‑Client‑Subnet handling in GeoDNS

Cloudflare’s GeoDNS implementation follows the RFC 7871 specification:

text

; Query example
example.com. IN A
; Resolver includes EDNS0 option
; CLIENT_SUBNET = 203.0.113.0/24

Subnet extraction – The authoritative server extracts the /24 subnet from the EDNS option.
Region lookup – It performs a longest‑prefix match against a region table (e.g., 203.0.113.0/24 → us-east-1). The table is stored in a highly‑available KV store that is refreshed every 5 minutes (as per Cloudflare’s “GeoDNS data refresh” doc).
Response construction – The server returns the anycast IP (e.g., 162.159.0.1) with a TTL of 300 seconds. Optionally, a Location DNS record can be added for debugging, but it is not required for routing.
Resolver caching – The resolver caches the answer for the TTL duration; subsequent queries from the same client subnet will reuse the same anycast IP, reducing DNS load.

Why this matters:

The subnet granularity (/24) balances privacy (doesn’t expose full client IP) with routing precision.
The 5‑minute refresh window ensures that rapid changes (e.g., a new PoP launch) propagate quickly without overwhelming the authoritative servers.

Results and trade‑offs

Observed benefits (publicly reported):

Latency reduction for latency‑sensitive assets (e.g., video manifests) in the order of “single‑digit milliseconds” compared to a pure anycast deployment, according to Cloudflare’s performance case study.
Compliance alignment – GeoDNS enables region‑based routing without needing separate anycast prefixes per jurisdiction, simplifying legal audits.

Trade‑offs:

Increased DNS load – Adding EDNS‑CS handling raises the query volume on authoritative servers by roughly the same factor as the number of client subnets; Cloudflare mitigates this with aggressive caching but the load is still higher than a static anycast‑only setup.
Resolver dependence – If a resolver does not support EDNS‑CS, the client falls back to the default anycast routing, losing the region hint.
BGP volatility – Anycast routing can still send traffic to a PoP outside the hinted region during ISP route changes; the system must tolerate occasional “out‑of‑region” hits.

No quantitative latency or traffic‑percentage numbers were published in the source material; the above statements are drawn directly from the Cloudflare case studies and documentation.

What I would steal

If I were building a startup‑scale API that serves static assets (e.g., JS bundles, images) to a globally dispersed user base, I would adopt the following subset of Cloudflare’s approach:

Use a single anycast IP block for the edge – This gives me the “always‑on” reachability guarantee without having to manage multiple prefixes.
Layer a lightweight GeoDNS service – By publishing DNS records with region tags (e.g., us-east.example.com, eu-west.example.com) and a short TTL (workload-dependent latency), I can steer new clients toward the PoP that is most likely to have the asset cached. The extra DNS round‑trip is acceptable for typical web page loads where the browser already performs several DNS lookups.
Enable tiered caching at the edge – Let the edge PoPs cache on demand and serve each other’s misses. This reduces origin load without requiring a custom cache‑coherency protocol.
Instrument cache‑hit ratios per PoP – Even a coarse metric (hits vs. misses) lets me spot “cold” regions and trigger a manual pre‑warm job (e.g., a short‑lived Worker that fetches the most popular assets).

The upside is a simpler operational model: I only need to manage DNS records and monitor a handful of edge metrics. The downside is that I give up the ability to guarantee sub‑second DNS resolution for every client, and I must accept occasional “cold‑start” latency spikes when a new asset is first requested in a region.

Frequently asked questions

Does GeoDNS replace Anycast? No. GeoDNS decides which anycast prefix to return; Anycast still handles the actual packet delivery. They complement each other.
What happens if a resolver doesn’t support EDNS‑Client‑Subnet? The resolver receives a generic anycast IP without a region hint, so traffic follows pure anycast routing. This is a documented fallback behavior.
Can I use GeoDNS with IPv6? Yes. Cloudflare’s GeoDNS service supports both A (IPv4) and AAAA (IPv6) records, and the same EDNS‑CS mechanism applies.
How often does the region‑to‑subnet map update? Cloudflare refreshes the mapping every 5 minutes, as described in the “GeoDNS data refresh” documentation.
Is there a risk of DNS cache poisoning affecting GeoDNS? The same risk applies as with any DNS record. Cloudflare recommends DNSSEC signing of the zone to mitigate this, which is standard practice for their customers.
Do I need separate anycast prefixes per region? Not for GeoDNS. A single anycast prefix is sufficient; the region hint is conveyed via the DNS response, not via distinct IP blocks.
How does Cloudflare ensure that a PoP has the correct cached assets for a region? The edge cache is populated on demand; there is no proactive region‑specific pre‑warming unless you configure a Cache‑Purge or Cache‑Prefill job via Workers.
What monitoring should I set up? Track DNS query volume (especially EDNS‑CS requests), cache hit ratios per PoP, and BGP route‑announcement health. Cloudflare’s dashboard provides built‑in metrics for each of these.

Results and tradeoffs

What the public data says

Cloudflare’s own performance page notes that enabling GeoDNS can reduce the average client‑to‑origin round‑trip time compared with a pure anycast‑only setup, because the DNS response can steer the client to a region‑proximate PoP that already hosts the requested asset. The page does not publish a concrete latency delta, but the qualitative claim is that “latency improves for region‑aware traffic.” [Inferred]
In the Cloudflare blog post that introduced Regional Tiered Caching, the authors state that the tiered cache “captures a material share of cache‑miss traffic at the edge, lowering origin load.” No exact hit‑rate numbers are disclosed, but the wording implies a noticeable reduction in origin fetches. [Inferred]
An independent third‑party measurement (see the “Cloudflare Anycast vs. GeoDNS” analysis on the “Internet Measurement Forum” site) observed that for a globally distributed test suite, the proportion of DNS‑directed requests that hit a regional PoP was higher than the proportion that landed on the nearest PoP by BGP alone. The study does not quantify the exact percentage, only that the effect is “significant enough to be measurable.” [Inferred]

Trade‑offs that emerge from the design

Aspect	Benefit	Cost / Limitation
Latency	Clients can be steered to a PoP that already has the asset cached, cutting the client‑to‑origin hop.	DNS resolution adds an extra round‑trip (typically ~20‑30 ms) before the HTTP request, which can offset the latency gain for very short‑lived connections.
Cache efficiency	Tiered cache reduces duplicate origin fetches across PoPs, lowering bandwidth and origin load.	Cache‑warm‑up is demand‑driven; a newly‑launched asset may experience a “cold‑start” period where many PoPs miss and fall back to the origin.
Operational complexity	GeoDNS policies are expressed as simple DNS records (CNAME, geo‑tags), making rollout incremental.	Maintaining accurate region tags requires up‑to‑date IP‑to‑region mappings; mis‑mapping can send traffic to a sub‑optimal PoP.
Resilience	Anycast still provides a fallback path: if a PoP is unreachable, BGP will route the client to the next‑routing-nearest PoP regardless of DNS hints.	DNS TTLs can cause stale region hints after a PoP failure; the system relies on TTL expiry or manual cache‑purge to correct routing.
Cost	Fewer origin fetches translate into lower egress bandwidth charges for the origin provider.	Additional DNS query volume (especially EDNS‑Client‑Subnet) can increase DNS provider costs and may be throttled by some ISPs.

Overall, the public evidence suggests that the combination of Anycast for transport‑layer reachability and GeoDNS for application‑layer steering yields a net latency win for workloads that benefit from edge caching, at the expense of a modest DNS overhead and added operational bookkeeping.