How GeoDNS and DNS-Based Load Balancing Actually Work

Quick Answer

GeoDNS and DNS-based load balancing use the DNS resolution step itself to send different users to different servers, by returning different IP addresses for the same domain based on location, measured latency, or server health. It's a real technique AWS Route 53 and Cloudflare both ship, but because DNS answers get cached by resolvers for their TTL, it reacts to failures and traffic shifts far slower than a real load balancer sitting in the request path.

DNS Doesn't Have to Give Everyone the Same Answer

The normal mental model of DNS is a phone book: you ask for priodemy.com, you get back one IP address, every time, from anywhere. Nothing about the DNS protocol actually requires that. An authoritative DNS server is free to look at who's asking and where the question came from, and hand back a different answer depending on that. That's the entire trick behind GeoDNS and DNS-based load balancing: instead of routing traffic after it arrives at your servers, you route it one step earlier, at the moment someone resolves your domain name into an IP address.

This post assumes you already know what a DNS record and a TTL are, and what a traditional load balancer sitting in front of a server pool does — we've covered both of those on this site before, in the DNS fundamentals piece and the load balancers piece. What we're covering here is the specific, narrower technique of using DNS itself as the routing decision: sending a user in Mumbai to a different server than a user in Frankfurt, purely by answering their DNS query differently, and the very real limitation that comes with doing routing at the DNS layer instead of the request layer.

How GeoDNS Actually Decides Which IP to Hand Back

Here's the mechanism. When your laptop wants to resolve priodemy.com, it doesn't talk to Priodemy's DNS server directly — it asks a recursive resolver (your ISP's, your router's, or a public one like 8.8.8.8). That resolver is the one that actually contacts the authoritative DNS server for the domain. A GeoDNS-capable authoritative server looks at the IP address of the resolver making that request, maps it to an approximate geographic location using an IP-to-location database, and returns whichever server's IP address makes sense for that location — say, a Mumbai data center for an Indian resolver and a Virginia one for a US resolver.

Notice the detail that trips people up: it's the resolver's location being used, not the end user's actual device. Most of the time this is close enough, because ISPs run resolvers near their own users. It falls apart when someone uses a resolver that isn't anywhere near them — a public DNS service, a VPN, or a corporate resolver in a different country. The fix for this is a real, documented DNS extension called EDNS Client Subnet (ECS): a supporting resolver forwards a truncated version of the actual user's IP address along with the query, so the authoritative server can make its geographic decision based on the user, not the resolver standing in for them. AWS documents this directly for Route 53 — when a resolver supports the edns-client-subnet extension of EDNS0, Route 53 uses that truncated address for its latency-based routing decisions. Cloudflare's load balancer has an equivalent setting, letting you choose between resolving location from the resolver's IP or preferring ECS data when it's available.

Geolocation Routing and Latency-Based Routing Are Not the Same Thing

AWS Route 53 ships both of these as separate, named routing policies, and it's worth being precise about the difference because they solve different problems.

Geolocation routing is explicit: you tell it 'queries from this continent, country, or US state go to this resource.' Per AWS's own documentation, this exists for use cases like showing content in a user's language, or restricting content to only the regions you have distribution rights for — it's a business-rules tool, not strictly a performance one. It comes with a real footgun: geolocation works by mapping IP addresses to locations, and some IPs simply aren't mapped to anything. If you don't create a default record to catch unmapped or uncovered locations, Route 53 returns a flat 'no answer' for those queries — which quietly breaks the site for whoever it happens to.

Latency-based routing is a different policy entirely. You create latency records for your resources across multiple AWS Regions, and when a query comes in, Route 53 checks its own measured latency data between the resolver and each of those regions, then returns whichever region is fastest — not whichever is geographically closest. AWS's documentation gives a concrete example: a user in London might get routed to Oregon or to Singapore, purely depending on which region has measured lower network latency from London at that time — and that answer can genuinely flip from week to week as internet routing and congestion shift, since it's based on ongoing measurement, not a fixed map. One more precise detail from AWS's docs: pure latency routing has no way to bias traffic toward a preferred region even if two regions are close in latency — if you need that kind of weighting, that's what Route 53's geoproximity routing (part of Traffic Flow) is for.

How Cloudflare's Load Balancer Layers Geo Steering on Top of DNS

Cloudflare's load balancing product documents its own version of this, called geo steering, and it's structured as a fallback hierarchy rather than a single flat rule. Per Cloudflare's documentation, you can steer at four levels, checked in order: specific data center (PoP) pools, then country-level pools, then region-level pools (13 broad global regions), then a default pool that catches anything not explicitly matched. A request for a country you haven't configured falls through to its region's rule; a request for a region you haven't configured falls through to the default. You don't have to enumerate every country on earth for this to work correctly.

Cloudflare's docs are also explicit about how a client's location is determined in the first place: 'the region of a client is determined by the region of the Cloudflare data center that answers the client's DNS query' — which is a direct consequence of Cloudflare running an anycast network, a detail worth sitting with for a second. It also matters where Cloudflare's DNS TTL guidance shows up: Cloudflare's own example configuration for a DNS-only (un-proxied, 'gray-clouded') load balancer record uses a 30-second TTL. That's deliberately short — for a record where the DNS answer is the actual routing decision, a low TTL is what lets Cloudflare react and reroute reasonably quickly if a pool becomes unhealthy. A proxied ('orange-clouded') record sidesteps this problem in a different way entirely: DNS just points to Cloudflare's anycast IPs permanently, and the actual origin-picking happens after the request has already arrived at Cloudflare's edge — which is a load-balancer-style decision, not a DNS one, and isn't bound by DNS caching at all.

The TTL Problem: Why DNS Routing Is Coarse and Slow

This is the part that makes DNS-based load balancing fundamentally different from a real load balancer, and it's worth being blunt about it. Once a resolver receives your DNS answer, it caches it for the record's TTL — and it isn't just that one resolver. Every hop between the authoritative server and the end user (the ISP's resolver, sometimes the OS, sometimes the browser) can cache its own copy. If a 300-second TTL answer gets cached right before the server it points to dies, every single client that resolved through that cache is stuck being sent to a dead server for up to five minutes, no matter how fast your monitoring detects the failure.

Compare that to what a real load balancer does, sitting in the actual request path: it checks the health of backend servers on its own schedule — typically a handful of seconds per health check interval — and the moment a backend fails a check, it simply stops sending it new requests. There's no caching layer for a hundred million other devices to have to individually expire. This is the honest reason DNS-based routing is treated as a coarse, first-line tool — 'send this whole region toward this data center' — rather than the actual per-request load-spreading decision, which is what a load balancer is for. Even with a low TTL, some resolvers on the internet are known to ignore small TTL values and cache longer anyway to cut down their own query volume, which means DNS-based failover should be assumed to be minutes-scale in the worst case, not seconds-scale, even when you've configured it aggressively.

DNS Failover, and Why Big Networks Reach for Anycast Instead

Both Route 53 and Cloudflare run active health checks against the actual endpoints behind their DNS answers, and pull unhealthy ones out of rotation automatically — this is what people mean by 'DNS failover.' It's a genuinely useful capability, and it's the reason Cloudflare's own example load balancer configuration keeps that TTL down at 30 seconds: detection can be fast, but propagation of the corrected answer is still bounded by however long the stale answer sits in caches around the internet.

This is exactly why services that need to react to failure in seconds rather than minutes — big CDNs, DNS resolvers themselves, major cloud load-balanced endpoints — often reach for anycast addressing instead of, or in addition to, GeoDNS. With anycast, the exact same IP address is announced from many physical locations simultaneously, and it's internet routing (BGP) that decides, packet by packet, which physical location a given user's traffic actually reaches. Pull one location out of the announcement and traffic reroutes at the routing-table level, which reacts on the order of the routing protocol's convergence time — no DNS cache anywhere has to expire first, because the same IP address never changed. GeoDNS and anycast solve a similar-sounding problem but at genuinely different layers, and most large-scale global services you use every day are actually running both at once, at different points in their stack.

When You Need This vs When You Need a Real Load Balancer

In practice, layer these rather than picking one. GeoDNS or latency-based routing answers the coarse question: which data center or region should this user talk to at all? That decision changes rarely and tolerates being slow to update. A regional load balancer then answers the fine-grained question behind that: of the servers actually running in that data center right now, which one should handle this specific request? That decision has to be instant and has to react to a single server dying without waiting on anything to expire.

If you're running a single-region app, you don't need any of this — a normal load balancer in front of your servers, as covered in our load balancers piece, is the entire answer. If you're running infrastructure in more than one region or country and care about routing users to the nearest or fastest one, DNS-based routing is the standard, well-documented way to make that top-level decision — just go in with accurate expectations about its reaction time, and don't ask it to do a real load balancer's job.

Frequently Asked Questions