Latency-Based vs. Geolocation-Based DNS Routing

Both route a DNS query to a different answer depending on the requester, but on different signals. Latency-based routing uses measured network latency data between the resolver's location and each candidate region, sending the user to whichever region actually responds fastest — which is not always the geographically nearest one, since network topology and peering agreements don't perfectly mirror physical distance. Geolocation-based routing uses the resolver's inferred geographic location directly, which is the right tool when the requirement is about the user's actual jurisdiction — data residency compliance, region-specific content, or regulatory restrictions — rather than pure speed.

A common mistake is defaulting to geolocation routing for a pure performance goal. It's simpler to reason about, but it can send a user to a "nearby" region that's actually slower than a slightly more distant one with better network peering. When the goal is speed, latency-based routing measured against real network conditions is the more accurate tool.

Where DNS Routing Falls Short

DNS routing operates at the granularity of a full resolution — once a client or intermediate resolver caches an answer, it keeps using that answer until the TTL expires, regardless of whether the underlying health state changed in the meantime. This is fine for routing decisions that change rarely, but it's a poor fit for fast failover (Article 2 covers this) and it can't route individual requests differently — every request from a given cached resolver goes to the same place until the cache expires, which limits how precisely traffic can be balanced or shifted.

Anycast: Routing Below the Application

Anycast announces the same IP address from multiple physical locations via BGP, and the network itself — not DNS, not the application — decides which location a given packet reaches, based on routing topology at the moment of the request. This is what underlies AWS Global Accelerator and most major CDN edge networks: a single stable IP address that transparently routes different users to different physical points of presence, and reroutes automatically and near-instantly if a location becomes unreachable, without any DNS change or cache expiry involved at all.

The trade-off is that Anycast infrastructure is typically something you consume from a cloud or CDN provider rather than build yourself — running your own Anycast network requires BGP peering relationships and infrastructure most teams don't want to own. For most systems, the practical choice is which managed Anycast-backed service to route through, not whether to build Anycast from scratch.

A layered approach that holds up in practice

A durable pattern: use a CDN's Anycast edge network for content that can be cached or accelerated at the edge; use a global accelerator (also Anycast-backed) for dynamic, uncacheable API traffic that needs to reach an origin over the provider's private backbone rather than the public internet; and use latency-based DNS as the outer layer that both of the above sit behind, mainly to handle coarse-grained regional traffic distribution and health-based failover as a backstop. Each layer compensates for the others' weak points — DNS's cache-staleness problem is masked by Anycast's near-instant rerouting underneath it.

CDN Edge Networks: More Than Caching

A CDN's core job is caching static and cacheable content close to users, cutting both latency and origin load. But modern CDN platforms increasingly do useful work beyond caching that matters for multi-region routing specifically: edge-level health awareness that can route around an unhealthy origin region automatically; edge compute (small functions running at the edge) that can make routing or personalization decisions without a round trip to origin at all; and integrated WAF and bot mitigation that filters malicious traffic before it ever reaches the origin's compute, which matters directly for the request path covered in the next article.

Choosing a Routing Strategy: A Practical Framework

  • Mostly static or cacheable content, global audience: CDN edge caching does most of the work; DNS routing to origin only matters for cache misses and dynamic fallback.
  • Dynamic API traffic, latency-sensitive: global accelerator (Anycast) for the transport layer, combined with latency-based DNS as the outer control and failover backstop.
  • Regulatory or data-residency requirements: geolocation-based DNS routing, often combined with application-layer checks as a second line of defense — DNS routing alone shouldn't be the sole enforcement mechanism for a compliance requirement, since a client can bypass DNS-based routing by hardcoding an IP.
  • Cost-constrained, availability need is modest: DNS-based failover alone, accepting the propagation delay discussed in Article 2, may be the right trade-off — not every system needs Anycast-backed infrastructure.

Verifying Routing Actually Works as Designed

Routing configuration is deceptively easy to get subtly wrong — a latency-based record with only two of three regions configured, a health check pointing at the wrong endpoint, a CDN cache rule that accidentally caches a personalized response. Distributed synthetic monitoring, issuing test requests from multiple real-world geographic vantage points on a continuous schedule, catches these before real users do. This is worth treating as a permanent piece of observability infrastructure (revisited in Article 10), not a one-time launch check.

Frequently Asked Questions

Should I use latency-based or geolocation-based DNS routing?
Latency-based routing for performance optimization, since it routes by measured network latency rather than assumed geographic proximity, which don't always correlate. Geolocation-based routing is the right choice when the requirement is regulatory or business — restricting or customizing content by a user's actual location, such as data residency rules — rather than pure speed.

Do I need a global accelerator if I already have a CDN?
It depends what's being routed. A CDN excels at caching and serving static or cacheable content from edge locations. A global accelerator adds value for dynamic, uncacheable traffic — API calls, WebSocket connections, anything that must reach an origin server — by routing it over the cloud provider's private backbone instead of the public internet. Many production systems use both for their respective traffic types.

How do I test global routing without waiting for real users in each region?
Use distributed synthetic monitoring — a service that issues requests from many geographic vantage points on a schedule and reports latency and routing outcome per location. This validates that routing behaves as designed before real user traffic reveals a misconfiguration, and it's cheap enough to run continuously, not just before a launch.