Skip to main content
Cloud & AI Hub
Browse
Glossary AI Directory Playgrounds Models Prompts Explainers Strategy Matrix Benchmark Decoder

GeoDNS

DNS that answers differently based on where the query comes from — routing users to the nearest or most appropriate region at the resolution layer.

What is GeoDNS?

GeoDNS returns different DNS answers depending on the geographic location of the resolver making the query. Ask for app.example.com from Europe and get the EU server’s IP; ask from Asia and get the Singapore server’s — same name, location-aware answer. It steers users to the nearest or most appropriate endpoint at the resolution layer, before any connection is made, which is why it’s a foundational tool for global applications (Route 53’s geolocation and latency routing policies are GeoDNS).

What it’s used for

Three main jobs. Latency reduction: route users to the geographically (or network-topologically) nearest region so requests travel less far — the performance play, closely related to how CDNs and anycast work, but decided at DNS time rather than routing time. Data residency and compliance: pin European users to EU infrastructure so their data stays in-region (a GDPR-shaped requirement that DNS can help enforce at the entry point). Traffic distribution and failover: send regions to their designated deployments, and reroute away from a failed region. It’s the DNS-layer complement to anycast — where anycast uses one IP the network routes, GeoDNS hands out different IPs based on where you asked.

The limitations that bite

GeoDNS decisions are only as accurate as resolver geolocation, and that’s imperfect: DNS servers see the resolver’s location, not the user’s, so a user on a centralized public resolver (or a corporate DNS that egresses from one region) may get answers targeted at the resolver’s location, not theirs — the EDNS Client Subnet extension partially fixes this by passing a truncated client IP, but it’s not universal. The other constraint is TTL: like all DNS-based routing, GeoDNS changes propagate only as fast as caches expire, so failover and re-routing aren’t instant — resolvers keep serving cached answers until TTL lapses. And it routes at connection start; it can’t move an in-flight session.

What people get wrong

  • Assuming resolver location equals user location — public and corporate resolvers can send users to the “wrong” region without EDNS Client Subnet.
  • Expecting instant failover: TTL bounds how fast GeoDNS re-routing takes effect — set TTLs with failover needs in mind.
  • GeoDNS instead of a CDN for static content — a CDN caches content at the edge; GeoDNS only directs which origin to hit.

Primary source: AWS Route 53 — geolocation routing

Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.