GeoDNS

When you type a domain into a browser, your computer asks a DNS resolver for the IP address behind that name. Ordinary DNS gives every caller the same answer. GeoDNS changes the answer based on who is asking, specifically based on their approximate physical location.

The authoritative DNS server looks at the source IP of the incoming query, maps it to a country or region, and returns a record from a pool that matches that region. So example.com might resolve to 203.0.113.10 (a server in Virginia) for a request from the United States, and to 198.51.100.20 (a server in Singapore) for a request from Indonesia.

GeoDNS is a routing decision made at name-resolution time, before any actual connection to your servers happens. It does not move data or proxy traffic. It only hands out a different address so the user connects directly to a server that is close to them.

The key input is the client IP seen by the authoritative server. In most cases that is the IP of the user's recursive resolver (for example their ISP or a public resolver like 8.8.8.8), not the user's own device. The DNS server matches that IP against a geolocation database such as MaxMind GeoIP2 to guess a location, then picks the closest configured pool of records.

Because the resolver IP is used, accuracy depends on the user querying a nearby resolver. If someone in India uses a resolver hosted in the US, GeoDNS may route them to a US server. The EDNS Client Subnet extension (ECS, RFC 7871) fixes much of this by letting the resolver forward a truncated version of the real client subnet, so the authoritative server sees roughly where the user is.

TTL matters a lot. A short TTL such as 30 to 60 seconds lets you reroute users quickly during a regional outage, but it increases DNS query volume. A long TTL means clients cache the regional IP for hours and ignore later geo decisions until the cache expires.

Many GeoDNS systems also fold in health checks. If the closest region is failing its health check, the resolver returns the next-best region instead, which turns GeoDNS into a basic global failover mechanism rather than pure proximity routing.

Reach for GeoDNS when you run servers in more than one region and want each user to hit the nearest one for lower latency, or when you need data residency, so European users land on EU infrastructure for GDPR reasons. It is also a cheap way to do active-active multi-region failover at the DNS layer.

The big limitation is granularity. Geolocation by resolver IP is approximate, you cannot route on real client load, and DNS caching means routing decisions are sticky for at least one TTL. GeoDNS also cannot react within a single connection, since the decision is already made by the time the TCP handshake starts.

For latency-sensitive global traffic, Anycast often beats or complements GeoDNS. With Anycast the same IP is announced from many locations and the network routes the user to the nearest one, with no dependence on geolocation databases or DNS caching. A common production pattern is GeoDNS for coarse regional steering plus Anycast inside each region for fine-grained edge selection.

Suppose you run a SaaS app with clusters in us-east-1 (Virginia), eu-west-1 (Ireland), and ap-south-1 (Mumbai). You configure GeoDNS on app.example.com with three pools, one per region, and attach an HTTP health check to each.

A user in Pune queries DNS. Their ISP resolver, located in India, hits your authoritative DNS. The geo lookup maps the resolver IP to India, so the server returns the Mumbai cluster IP. The user connects to a server roughly 150 km away instead of one across an ocean, and round-trip latency drops from around 250 ms to under 30 ms.

Now the Mumbai cluster fails its health check. On the next DNS query the resolver returns the Ireland IP instead. Indian users see slower responses for a short window but the app stays up. Once Mumbai recovers and passes health checks again, GeoDNS resumes sending Indian traffic there.