Anycast, GeoDNS and traffic steering
Anycast routing and where it fails, latency and geolocation policies, weighted and failover records with health checks, and when steering adds more risk than value.
Anycast and GeoDNS are different
Anycast advertises the same IP address from many locations and lets the network routing decide which one a client reaches. GeoDNS is a DNS feature: the authoritative server returns a different answer based on who is asking. They solve the same problem from opposite directions, and most large services use both.
| Anycast | GeoDNS | |
|---|---|---|
| Decided by | BGP routing | The authoritative server |
| Granularity | Network topology | Region, country, continent, ASN |
| Failover | Routing withdraws the prefix | Health check removes an answer |
| Client effort | None | A new lookup is needed |
| Weakness | Route flapping, asymmetric paths | Resolver location is a poor proxy for user location |
| Cache interaction | Transparent | Answers are cached, so a change is delayed |
- Public resolvers do not sit next to your users. A user in one country may be served by a resolver in another, which breaks geolocation policies and is the single most common reason a regional rule misfires.
- With DNS-over-HTTPS and DNS-over-TLS, the client chose the resolver explicitly, so the resolver's location is even less informative.
- Anycast failures are usually BGP problems - a withdrawn route or a flapping session - which look exactly like an origin outage from the outside.
Routing policies that earn their keep
| Policy | Behaviour | Good use | Bad use |
|---|---|---|---|
| Failover | Primary, secondary on health failure | An active-passive pair | More than two levels |
| Weighted | Split by percentage | A staged rollout of a new origin | Long-term load balancing |
| Latency | Answer from the fastest region per client | Global services with regional backends | Backends that are not equivalent |
| Geolocation | Answer by user region | Data residency and localisation | Cost saving on bandwidth alone |
| Multivalue | Return several healthy answers | Simple client-side spreading | Load balancing, because clients choose arbitrarily |
A defensible steering setup
health check HTTPS against /healthz, 3 failures to mark down,
60 second interval, 3 regions of checkers
failover primary region, secondary region, no tertiary
TTL 60 for steering records, 300 for static ones
weight start at 5 percent, not 50
alarm on health-check flapping, not just on "down"
If the health check only tests TCP 443, a broken application
behind a live load balancer keeps receiving traffic.Weighted records are not load balancers. Resolvers cache answers for the TTL, so the split is approximate and sticky, and a client that has resolved once keeps using the same answer for the whole TTL. Use weights for a rollout, not to balance a real load.
When steering does more harm than good
- Keep the number of moving parts small. Each health check, weight and policy is another way for the system to be confidently wrong.
- Verify that the health check measures what users experience. A TCP check on a port proves nothing about the application behind it.
- Make sure the failure mode is understood. TTL caching means DNS failover takes at least one TTL to take effect, plus the resolver's own behaviour.
- Test the failover on purpose, on a schedule. An untested failover is a plan, not a capability.
- Have a single static record as the last resort. When steering misbehaves, pointing the name at one known-good address is the fastest fix.
# watch which answers a resolver gives you over time
for i in $(seq 1 10); do
dig +short www.example.com @1.1.1.1 | tr '\n' ' '
echo
sleep 3
done
# and confirm a specific region's answer by querying an authoritative server
dig +short www.example.com @ns1.example.com⚠️
A health check that flaps causes a resolver to alternate answers, and clients then experience a partly broken service with no clear signal anywhere. Set the failure threshold high enough that a single dropped probe does not mark a healthy region down - three consecutive failures is a reasonable floor.
FAQ
Does anycast replace a load balancer?
No. Anycast steers a client to a nearby entry point; how traffic is spread across servers behind that point is still a load balancing problem.
How fast is DNS failover?
As fast as the shortest TTL in the chain, plus however long the resolver takes to notice. A 60-second TTL does not mean 60 seconds - clients that resolved just before the failure keep using the old answer for a full minute.
Related
IPv6 and dual-stack DNS DNSSEC and DNS security
Last refreshed 2026-09-18.