Andrew Mercer
on this page

1. What This Solves

Plain DNS returns the same answer to every client, regardless of where that client is in the world. For a globally distributed service, that's a missed opportunity at best (a user in Sydney getting routed to a server in Virginia when a Sydney data center exists) and a real availability/compliance problem at worst. Geolocation and proximity-based DNS routing solve this by having the authoritative server itself decide which answer to give based on something about the querying client — most commonly its apparent location, but also (in "proximity" specifically) a blend of location and the size/bias of the resource pool serving that region.

This is a feature of specific DNS providers/servers, not a core DNS protocol capability — plain DNS as specified in RFC 1035 has no notion of "give a different answer based on where the query came from." It's implemented at the authoritative-server layer, most commonly through managed cloud DNS providers, though open-source options exist too (PowerDNS's GeoIP backend, and octoDNS's dynamic records covered in the octoDNS guide, which can drive several backends' geo features from one declarative source).

2. How the Server Determines "Where" a Client Is

The authoritative server doesn't see the actual end-user client directly in most cases — it sees the resolver making the query on the client's behalf (recall the recursive/authoritative distinction from the general DNS guide). This introduces a real accuracy gap: if a user's resolver is geographically distant from the user themselves (a VPN, a public DNS provider like 8.8.8.8 with resolvers not necessarily near the querying client), geolocation-based routing sees the resolver's location, not the user's.

EDNS Client Subnet (ECS, RFC 7871) exists specifically to close this gap: a resolver that supports ECS includes a truncated portion of the original client's IP subnet in its query to the authoritative server, letting the authoritative server route based on the actual client's approximate location even though the resolver itself might be far away. Large public resolvers (Google, Cloudflare — though Cloudflare's 1.1.1.1 notably opts out of ECS by policy for privacy reasons) and most major cloud DNS providers support ECS on both ends; when it's unsupported anywhere in the chain, geo-routing falls back to using the querying resolver's own location as the proxy for the client's.

3. Routing Policy Types (Using Route 53's Terminology, Broadly Representative)

Policy Decision basis
Geolocation Client's (or ECS-supplied) geographic location (continent/country/state) maps to a specific, fixed answer — used when routing needs to follow legal/regulatory or content-licensing boundaries, not just performance
Latency-based Which region's endpoint has historically had the lowest measured latency to the querying resolver's network location — optimizes for speed, not strict geographic correctness
Geoproximity Like geolocation, but with a bias value that can expand or shrink a given endpoint's effective catchment area — used for gradually shifting more or less traffic toward a region without a hard cutover
Weighted Simple percentage-based traffic splitting, no location awareness at all — often combined with the above for canary releases or A/B infrastructure testing within a geo-routed setup
Failover Health-check-driven: route to a primary, or fail over to a secondary the moment the primary is detected unhealthy — often layered underneath a geo policy so each region has its own local failover pair
Multivalue answer Return several healthy IPs and let the client pick — simple DNS-level load distribution with health checking, without true geo logic

Real-world configurations frequently layer these: geolocation or geoproximity to pick the right region, then a health-check-driven failover within that region's chosen endpoint, so the system handles both "route the user to the right place" and "route around a local outage" simultaneously.

4. Health Checks Are Load-Bearing

Geo-routing without health checking is fragile — sending users to "the nearest region" does nothing useful if that region's actual service is down. Managed DNS geo-routing features are near-universally paired with active health checks: the DNS provider (or a paired third-party monitoring service) periodically probes each candidate endpoint (HTTP/HTTPS/TCP checks), and any endpoint failing its health check is automatically excluded from being returned as an answer — the region "disappears" from DNS until it recovers, with clients then landing on the next-best geographically appropriate healthy option instead.

This is also precisely where DNS TTLs become an operational constraint on failover speed (see the general DNS guide, §6): a low TTL (30–60 seconds is common for actively health-checked, geo-routed records) means clients notice a failover quickly; a long TTL means cached-but-now-wrong answers linger in resolvers around the world for however long that TTL specifies, regardless of how fast the DNS provider itself reacts.

5. Example: Route 53 Geolocation (via octoDNS, tying back to that guide)

www:
  type: A
  dynamic:
    pools:
      na-pool:
        values:
          - value: 192.0.2.10
      eu-pool:
        values:
          - value: 192.0.2.20
      apac-pool:
        values:
          - value: 192.0.2.30
    rules:
      - geos: ["NA"]
        pool: na-pool
      - geos: ["EU"]
        pool: eu-pool
      - geos: ["AS", "OC"]
        pool: apac-pool
      - pool: na-pool   # default/fallback for unmatched geos
  value: 192.0.2.10

Each pool is a candidate answer set for a region; rules map continent/region codes to pools, with an unconditional final rule acting as the default for any client whose location doesn't match a more specific rule — every geo-routing configuration needs an explicit fallback, since a client's location will sometimes be unresolvable or fall outside every defined region.

6. Global Server Load Balancing (GSLB) — The Broader Term

"Geolocation DNS routing" is one implementation technique under the broader umbrella of Global Server Load Balancing (GSLB) — the general practice of directing client traffic to the best of several geographically distributed points of presence. DNS-based GSLB (what this guide covers) is popular because it requires no client-side changes and works with any protocol, but it has an inherent limitation worth naming: DNS's decision is made once, at resolution time, and then cached — it can't react to conditions that change during an already-established connection the way an in-path load balancer or CDN edge redirect can. This is why DNS-based GSLB is frequently paired with a CDN or global accelerator (e.g., AWS Global Accelerator, Cloudflare's network) layered on top, handling the finer-grained, connection-level routing decisions DNS's coarser, TTL-bound model can't.

7. When Geolocation Routing Is the Wrong Tool

  • Split-horizon needs (internal vs. external addressing) are a different problem entirely — see the split-horizon guide; geolocation routing operates entirely within "external, public clients," never toward distinguishing internal-network clients.
  • Simple redundancy without regional preference — if all your capacity is effectively one logical pool and you just want to spread load or fail over, weighted or multivalue-answer routing is simpler and avoids the ECS/ accuracy caveats of true geo-routing.
  • Sub-second failover requirements — DNS TTLs, however aggressively tuned, are not a substitute for connection-level failover (anycast plus BGP withdrawal, or an in-path load balancer) when outage detection-to-recovery needs to happen faster than a TTL cycle plus caches everywhere honoring it.
  • RFC 7871 — EDNS Client Subnet (ECS)
  • AWS Route 53 routing policies: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
  • Cloudflare's stance on ECS and privacy: https://blog.cloudflare.com/edns-client-subnet-1-1-1-1/
  • octoDNS dynamic records documentation: https://github.com/octodns/octodns#dynamic-records