Why is DNS a poor primary mechanism for fast failover, and what should be used instead for a globally distributed service?

Why DNS failover is unreliable

TTLs are advisory in practice. Recursive resolvers may enforce minimum TTLs of their own. Operating systems cache. Browsers cache independently and sometimes ignore both. Application runtimes cache resolutions for the process lifetime — a Java service that resolved a hostname at startup may never resolve it again. The result: after a 60-second TTL expires, a substantial tail of clients continues sending traffic to the dead endpoint for many minutes, sometimes hours.

Very short TTLs make it worse in a different way. They multiply query volume, increase dependence on DNS availability at exactly the wrong moment, and add a resolution round trip to a meaningful fraction of requests.

DNS has no view of health. It answers with what it was configured to answer. Health-checked DNS exists and helps, but it can only change the answer — it cannot recall the answers already cached everywhere.

Round-robin DNS distributes nothing usefully. Balance is per-resolver, not per-request, so a large corporate resolver sends all its users to one endpoint. And a failed endpoint stays in rotation until caches expire.

What to use instead

Anycast. The same address is announced from many locations, and network routing delivers each client to the topologically nearest one. Withdrawing the announcement from an unhealthy location moves traffic within seconds, with no client-side change and no cache to wait for. This is the standard mechanism for global CDN and DNS infrastructure.

Health-aware routing at a layer that sees the traffic — a load balancer or edge proxy that can redirect per-request rather than per-resolution.

Client-side endpoint lists. The client receives several endpoints and fails over itself. This is the most reliable layer, because it does not depend on any shared infrastructure resolving correctly, and it is why mature mobile SDKs and database drivers all do it.

Where DNS is still the right tool

DNS remains correct for coarse, slow-moving decisions: geographic steering, planned migrations, distributing across regions in normal operation. Its weakness is specifically fast, unplanned failover.

The clean division: DNS decides where you go in normal operation; anycast and health-aware routing decide what happens when something breaks. Systems relying on DNS for the second case discover the unbounded tail during their first regional incident.