GeoDNS: Location-based DNS Routing

When someone in Tokyo visits your website, they should reach servers in Asia. When someone in London visits the same site, they should connect to Europe. GeoDNS makes this happen by returning different IP addresses based on where the DNS query originates.

The same domain name, different destinations. DNS stops being a phone book and becomes a traffic cop—one that sees where you're standing and points you toward the nearest door.

What Is GeoDNS?

GeoDNS is DNS that gives different answers depending on who's asking. Instead of returning the same IP address to everyone, a GeoDNS-enabled authoritative nameserver examines where the request comes from, determines the geographic location, and responds with an IP address for a nearby server.

When your GeoDNS provider receives a query for www.example.com, it looks at the source IP address of the DNS resolver, determines its location using a geolocation database, and consults your routing policy. That policy might say: queries from Asia go to 203.0.113.10, queries from Europe go to 198.51.100.20, queries from North America go to 192.0.2.30.

Users type the same domain name regardless of where they are. The DNS system silently routes them to the optimal endpoint.

How Location Detection Works

GeoDNS uses two methods to figure out where you are, and both have blind spots.

Resolver IP Geolocation is the traditional approach. The GeoDNS server looks at the IP address of the DNS resolver making the query and uses a database (like MaxMind GeoIP2) to determine where that resolver sits.

The problem: the resolver's location might not be your location. If you're in Singapore but use Google's public DNS at 8.8.8.8, your query might route through Google's California infrastructure. The GeoDNS server thinks you're American and sends you to North American servers—while you're sitting in Asia wondering why everything is slow.

EDNS Client Subnet (ECS) fixes this. ECS lets DNS resolvers include part of your actual IP address in the query. Instead of the authoritative server seeing only "this query comes from 8.8.8.8," it sees "this query comes from 8.8.8.8 on behalf of a client in 203.0.113.0/24." Now it can route based on where you really are.

Major resolvers like Google Public DNS support ECS. Privacy-focused resolvers often don't—they intentionally avoid revealing client information. According to 2024 research from APNIC Labs, about 12% of Internet users are served by resolvers using ECS¹. A solid GeoDNS implementation handles both scenarios, falling back to resolver-based geolocation when ECS isn't available.

Why GeoDNS Matters

Content Delivery Networks are the most common use case. CDNs cache content at dozens or hundreds of edge locations worldwide. GeoDNS directs users to their nearest cache, slashing latency. A streaming service with edge servers in fifty cities can serve everyone through a single hostname that routes intelligently.

Global Load Balancing distributes traffic across data centers on different continents. Instead of funneling all traffic to one location, companies route each user to their nearest facility. When the European data center goes down, GeoDNS automatically sends European users to North America or Asia.

Regulatory Compliance increasingly requires GeoDNS. Data residency laws like GDPR demand that certain data stay within specific borders. GeoDNS ensures EU users connect to EU servers before any application code runs. The routing policy enforces legal boundaries at the infrastructure level.

Disaster Recovery uses GeoDNS for automated failover. When a region goes offline, DNS redirects affected users to healthy regions. It's not instantaneous—cached DNS answers persist until their TTL expires—but it provides infrastructure-level recovery without manual intervention.

The Core Assumption (and When It Breaks)

GeoDNS assumes proximity predicts performance. Route users to nearby servers, get lower latency. Usually this is true. Sometimes it's wrong.

The shortest path on a map isn't the shortest path on a network. Two cities 50 miles apart but in different countries might have completely different optimal routing. International borders create network boundaries that ignore proximity. A user in Vancouver might get better performance from Seattle than from Toronto, despite Toronto being in the same country.

Geolocation databases aren't perfect. Accuracy is decent in North America and Europe, shakier elsewhere. Mobile networks, VPNs, and corporate networks routinely confuse these databases. IP address allocations change constantly, and databases lag behind.

DNS caching delays everything. You can update your GeoDNS routing instantly, but clients holding cached answers keep using them until the TTL expires. Lower TTLs mean faster failover but higher query volume on your authoritative servers.

Not everyone uses ECS. Many resolvers don't support it, and privacy policies limit what subnet information gets shared even when they do. Your implementation must degrade gracefully when ECS isn't available.

Making GeoDNS Work

Start broad. Route by continent or country before attempting city-level precision. Broader regions are more reliable and less vulnerable to geolocation errors. Refine granularity once you understand your actual traffic patterns.

Measure actual performance, not assumed performance. Geographic proximity doesn't guarantee lower latency. Use real user monitoring to measure actual connection times from different regions to different endpoints. Sometimes users get better performance from a more distant data center because of how networks actually connect.

Set sensible TTLs. 300 seconds (5 minutes) balances responsiveness with query volume. Avoid TTLs below 60 seconds unless you have specific requirements and can handle the load.

Implement health checking. Your GeoDNS provider should actively monitor your endpoints and stop routing to anything that fails health checks. Without this, GeoDNS happily directs users to dead infrastructure.

Test from diverse resolvers. What works from Google Public DNS might route differently through an ISP resolver or corporate DNS. Test from multiple public resolvers, enterprise networks, and mobile carriers.

Define fallback routing. When geolocation fails or returns ambiguous results, have a sensible default. Route unknown locations to your largest or most reliable data center.

Provider Options

Several DNS providers offer GeoDNS with different capabilities:

• AWS Route 53 provides geolocation routing at continent, country, and US state levels, with geoproximity routing that can bias traffic toward or away from specific resources²
• Cloudflare includes geographic routing in their load balancing with active health checking
• IBM NS1 Connect offers sophisticated traffic management including real user monitoring data to route based on actual performance rather than assumed proximity³
• Oracle DNS (formerly Dyn) and UltraDNS provide enterprise-grade GeoDNS with detailed analytics

When evaluating providers, consider their geolocation database sources, update frequency, ECS support, health checking capabilities, and whether they can route based on actual measured performance rather than just geographic proximity.

Sources