GeoDNS vs anycast: two ways to send users to the nearest server
Two technologies promise the same thing — send each visitor to a nearby server — but they decide at different moments, and one of them has quietly got less accurate over the last few years.
If you have ever loaded a site and found yourself served from a data centre on the wrong continent for no discernible reason, you have met the difference between these two, and GeoDNS was almost certainly involved.
Both technologies exist to solve the same problem: get each visitor to a nearby server. They disagree about when to decide, and that timing difference produces everything else — the accuracy, the failover speed, the control you get and the ways each one fails.
GeoDNS decides at lookup time
GeoDNS makes its choice during the DNS lookup. A resolver asks "where is example.com?", the authoritative nameserver looks at where the question appears to come from, and returns the address of a server near there. Ask from Stockholm, get the Nordic edge. Ask from Sydney, get the Australian one.
The words doing the heavy lifting there are appears to come from. The nameserver does not see the visitor. It sees the recursive resolver asking on their behalf, which may be nowhere near them.
Anycast decides at connection time
Anycast does not guess at all. The same IP address is announced from every location, and when the visitor actually opens a connection, internet routing delivers their packets to whichever location is nearest by network path. There is no geography database to be wrong, because nothing is being looked up — the answer is a consequence of how the packets travel.
The resolver problem, and why it got worse
This is the crux, and it is more consequential than it was five years ago.
GeoDNS sees the source address of the resolver, not the visitor. If someone in Copenhagen uses their ISP's resolver, that resolver is probably also in Denmark and the guess is good. If they use a public resolver, the query may egress from a completely different country, and GeoDNS confidently returns a server near that.
There is a mechanism designed to fix exactly this: EDNS Client Subnet, an extension where the resolver includes a truncated version of the client's own network in the query, so the authoritative server can make a decision based on the actual visitor. When it is present, GeoDNS accuracy is good.
The difficulty is that ECS is optional and increasingly withheld. It is a privacy trade-off — it tells the authoritative nameserver something about who is asking — and several resolvers, particularly privacy-focused ones and some DNS-over-HTTPS implementations, deliberately do not send it. From the authoritative server's point of view the client's location simply is not available, and it falls back to the resolver's address.
The practical result is the behaviour people describe as routing "roulette": the same visitor on the same connection getting a different, sometimes distant, edge depending on which resolver their browser or operating system happens to be using that day. Nothing is misconfigured. The information needed to make the right choice never arrived.
Side by side
| GeoDNS | Anycast | |
|---|---|---|
| Decision point | DNS lookup | Packet routing |
| Based on | Resolver location, or ECS if sent | Actual network path |
| Accuracy with public or encrypted DNS | Degrades, sometimes badly | Unaffected |
| Failover speed | Capped by TTL and resolver behaviour | Seconds, via route withdrawal |
| Deterministic control | Full — you write the rules | Routing decides |
| Setup requirements | A DNS provider that supports it | Own IP space, ASN, BGP sessions |
| Compliance routing (keep region X in region X) | Straightforward | Hard to guarantee |
| Load balancing by capacity | Easy — weight the answers | No direct mechanism |
So which should you use?
For serving general web traffic to a global audience, anycast is the more robust choice, and the gap has widened as encrypted DNS has spread. It cannot be fooled about where a visitor is because it never asks.
GeoDNS remains the better tool when you need decisions that routing cannot express. If European visitors must be served from European infrastructure for compliance reasons, GeoDNS lets you state that as a rule; anycast lets you hope. If one location has more capacity than another, GeoDNS can weight traffic toward it. And GeoDNS is available to anyone with a suitable DNS provider, whereas anycast requires infrastructure most organisations will never own.
In practice large networks use both, and not as a compromise: anycast for the fast path where locality is the only goal, GeoDNS layered on top where a specific answer is required for a specific reason.
Frequently asked questions
What is the difference between GeoDNS and anycast?
GeoDNS chooses a server during the DNS lookup, returning a different IP address depending on where the query appears to originate. Anycast announces one IP address from many locations and lets internet routing deliver each connection to the nearest one. GeoDNS decides early from inferred location; anycast decides at connection time from the actual network path.
Why does GeoDNS send me to the wrong server?
Because it sees your DNS resolver's location rather than yours. If you use a public or encrypted DNS service whose query egresses from another country, GeoDNS will return a server near that country. The EDNS Client Subnet extension exists to pass along part of your own network address, but it is optional and many privacy-oriented resolvers deliberately omit it, leaving the authoritative server with no better information.
What is EDNS Client Subnet?
EDNS Client Subnet, or ECS, is a DNS extension that lets a recursive resolver include a truncated portion of the client's IP address in its query, so an authoritative nameserver can select a server near the actual visitor rather than near the resolver. It substantially improves GeoDNS accuracy, but it reveals information about the client and is therefore omitted by several privacy-focused and DNS-over-HTTPS resolvers.
Is anycast better than GeoDNS?
For general web traffic, usually yes — it is unaffected by which resolver a visitor uses and fails over within seconds rather than waiting for DNS caches to expire. GeoDNS remains better where you need deterministic control, such as keeping traffic from a region on specific infrastructure for compliance, or weighting traffic toward locations with more capacity. Large networks commonly use both together.
Can you use GeoDNS and anycast together?
Yes, and it is a common design. Anycast handles the default case, giving every visitor a nearby edge with fast failover, while GeoDNS is layered on top for the cases requiring a specific answer — regional compliance requirements, capacity weighting, or steering particular audiences to particular infrastructure. The two operate at different stages and do not conflict.
If you take one thing from the comparison: GeoDNS is an inference and anycast is a measurement. Inferences can be wrong, and over the last few years, as more traffic moved to encrypted and public DNS, they have been wrong more often.
See how NordicCDN does this for your site:
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
