GeoDNS steers DNS answers using available location signals, which often describe a resolver rather than an individual visitor.

You see the resolver, not the user

Authoritative DNS sees the recursive resolver. That is usually close to the user, not identical. Design fallbacks for resolvers that sit far from their users (some enterprise and public resolvers).

The delivery model

How it works

GeoDNS explained

  1. 01LocateUse resolver location or supported subnet information.
  2. 02SelectChoose a healthy destination under the routing policy.
  3. 03CacheThe answer can be reused for multiple clients.
Conceptual model for this configuration. The actual path depends on provider policy and application behavior.

Finer than country

Country maps are a start. ASN and subnet splits matter when a market shares a country with a different network path, or when you are canarying a carrier.

Health has to ride along

Steering to a nearby region that is down is worse than a farther region that works. Attach health checks so unhealthy endpoints leave the eligible set.

This is not a residency control

GeoDNS can send people toward in-region endpoints. It is not a legal guarantee. The application still has to enforce tenancy and data residency.

Validate before production

Query from representative networks and compare answers with the intended mapping. Test unknown locations and an all-unhealthy destination set. Use application-level controls for residency or authorization requirements rather than relying on DNS geography.

  • Record the configuration and expected result before changing traffic.
  • Keep evidence of the test and a working rollback for the previous behavior.

Sources & further reading