DNS Geographic Load Balancing and Where It Stops Working

Geographic DNS routing does not see your users. It sees the resolver asking on their behalf, and it hands out an answer that stays cached for as long as the TTL says.

Those two facts are the whole story of what geo DNS is good at and where it disappoints people. It is an excellent tool for steering traffic broadly and for satisfying data-residency rules. It is a poor tool for precise routing and a genuinely bad one for fast failover, and the marketing around it rarely says so.

How geographic routing actually works
The resolver problem
Why it is not a failover mechanism
When geo DNS is the right tool
What to use instead, and when
Setting it up without surprising yourself
How this fits the rest of the stack
FAQ

How geographic routing actually works

An authoritative nameserver that supports geographic routing keeps multiple answers for the same record and picks one based on where the query appears to come from. A visitor in Frankfurt gets the address of your European deployment; a visitor in Ohio gets the North American one. Nothing about the request itself is inspected, because DNS resolution happens before any HTTP connection exists.

That is the important structural point. The decision is made at name resolution, using only the source of the DNS query, and it is made once and then cached. Every subsequent request from that user goes wherever the cached answer points, regardless of what happens to your infrastructure in the meantime.

There are two distinct policies that get confused with each other. Geolocation routing maps a query’s apparent country or region to a specific endpoint, which is what you want for data residency and for serving country-specific content. Latency-based routing measures which of your regions is actually fastest from the querying network and picks that, which is what you want for performance. They frequently disagree, and the one you want is usually latency.

The resolver problem

The source of a DNS query is not the user. It is whatever recursive resolver they configured, and that can be a very long way away.

A user in Portugal on a corporate VPN whose DNS goes through a head office in Ireland resolves as Irish. A user on a public resolver may resolve from wherever that resolver’s nearest node happens to be, which is usually close but not always. A user behind a company that centralises DNS in one datacentre resolves as being in that datacentre, every time, no matter where they physically are.

There is a partial fix, EDNS Client Subnet, in which the resolver passes along a truncated portion of the client’s address so the authoritative server can make a better decision. It works well when supported, and support is inconsistent: some resolvers send it, some strip it for privacy reasons, and some send it only to certain authoritative servers.

So the practical accuracy of geo DNS is good at the continent level, decent at the country level, and unreliable below that. If your design depends on distinguishing two cities in the same country, it is the wrong mechanism.

Why it is not a failover mechanism

This is the expectation gap that causes real incidents. Geo DNS with health checks is often sold as automatic failover, and the health check part genuinely works: the provider probes your endpoints and stops handing out the address of a dead one within seconds.

The problem is everyone who already has the answer. A record with a 300-second TTL can be cached by resolvers for five minutes, so users keep being sent to the dead endpoint for up to that long after the provider stopped advertising it. Browsers cache independently of the OS, the OS caches independently of the resolver, and some resolvers ignore short TTLs entirely and apply a floor of their own.

Lowering the TTL helps and costs you something. A 30-second TTL means far more queries, which is more money on a per-query DNS bill and more load on the resolution path, and it still does not bind clients that cache aggressively. Below about 30 seconds you are mostly paying for the illusion of control.

If you need failover measured in seconds rather than minutes, the answer is not DNS. It is anycast, where the same address is announced from multiple locations and the network routes around a failure, or a load balancer in front of your endpoints that fails over behind a single stable address.

When geo DNS is the right tool

None of the above makes it useless. It is the right mechanism in four cases, and in these it is hard to beat.

Data residency. When European users must be served from European infrastructure for legal reasons, routing at the DNS layer is a clean, auditable way to enforce it.
Coarse traffic steering. Splitting a global audience across two or three regional deployments to reduce round-trip time. Continent-level accuracy is fine for this.
Country-specific content or pricing. Sending visitors to a localised deployment where the difference is content rather than latency.
Gradual regional rollout. Directing one region to a new deployment while the rest stay put, as a lower-risk alternative to a global cutover.

What these have in common is that they tolerate minutes of imprecision and do not depend on any individual user landing in exactly the right place.

What to use instead, and when

Three alternatives cover most of what people reach for geo DNS to do, and they are usually the better fit.

A CDN. If the goal is fast static assets close to users, a content delivery network already does this at the edge, with no DNS games and failover that happens in the network rather than in a cache. For most sites, this is the whole answer.
Anycast. One address announced from many locations. Routing decisions are made per-packet by the internet’s own routing, so failover is fast and there is no cache to wait out. It requires infrastructure most teams do not operate themselves, which is precisely why it usually arrives as part of a provider’s platform.
A single well-placed origin plus caching. The unglamorous option and often the correct one. A large share of sites that consider multi-region routing have a latency problem that is really an unoptimised origin, and moving one deployment closer to the majority of users plus caching aggressively beats a complicated global topology.

The honest ordering: fix the origin, add a CDN, and only then consider routing users to genuinely separate regional deployments. Multi-region is an operational commitment, not a configuration setting. Two deployments means two sets of deploys, two databases to keep consistent, and a new class of bug where a user’s session exists in one region and not the other.

Setting it up without surprising yourself

If you have decided you need it, a few practices keep it from biting.

Always configure a default answer. Geolocation policies match specific regions, and a query that matches nothing gets no answer at all unless you have set a catch-all. This is the classic geo DNS outage: traffic from an unmapped country simply fails to resolve.
Set the TTL deliberately and write down why. 60 seconds is a reasonable compromise for a record you may need to move. Understand that it is a floor on your recovery time, not a guarantee.
Health-check something meaningful. A check that hits a static file confirms the web server is alive and tells you nothing about whether the application can reach its database. Check a path that exercises the dependency you actually care about.
Test from more than one place. Resolve the record from several networks and confirm the answers are what you expect. A DNS lookup tool with multiple vantage points does this in seconds and catches a misconfigured region before users do.
Keep the regional deployments identical. The moment they drift, geo routing becomes a way of giving some of your users a different version of your product.

And keep the zone somewhere you can edit under pressure. The worst time to discover that your DNS provider’s console needs a password reset is the moment you need to move a record.

How this fits the rest of the stack

Geographic routing is a question about how many deployments you are willing to run, and that is a cost question before it is a technical one. Two regions means two of everything: two services, two databases, two sets of storage and bandwidth, plus the operational overhead of keeping them the same. Pricing a single deployment properly first is usually clarifying, because a fast origin with sensible caching solves the problem for a lot of sites at a fraction of the complexity. The RunxBuild hosting calculator lays out those line items so you can see what a second region would actually add before committing to the topology. Custom domains and certificates are handled per deployment, so pointing a record at a service is a DNS change and nothing more.

Useful related references:

FAQ

What is DNS geographic load balancing?

It is an authoritative nameserver holding several answers for the same record and returning a different one depending on where the DNS query appears to come from. A European visitor gets a European endpoint, a North American visitor gets a North American one. The decision happens at name resolution, before any connection is made, and the answer is then cached.

Is geolocation routing the same as latency-based routing?

No. Geolocation routing maps an apparent region to a specific endpoint, which is what you want for data residency and country-specific content. Latency-based routing picks whichever of your regions is measurably fastest from the querying network, which is what you want for performance. They often disagree, and for speed the latency policy is usually the right choice.

How accurate is geo DNS?

Good at continent level, reasonable at country level, unreliable below that. The authoritative server sees the recursive resolver, not the user, so anyone on a VPN or a centralised corporate resolver is located wherever their resolver is. EDNS Client Subnet improves this by passing along part of the client address, but support for it is inconsistent.

Can I use DNS for failover?

Only if you can tolerate minutes of downtime. Health checks stop your provider handing out a dead endpoint within seconds, but every resolver, operating system, and browser that already cached the old answer keeps using it until the TTL expires, and some ignore short TTLs. For failover measured in seconds, use anycast or a load balancer behind a single stable address.

What TTL should I use for a geo-routed record?

Around 60 seconds is a workable compromise. Shorter increases query volume and cost without reliably reaching clients that cache aggressively; longer makes any change, including failover, slower to take effect. Treat whatever you pick as the floor on how fast you can move traffic.