DNS Failover Explained: How It Works, TTL, and Its Limits
DNS failover is an automated routing technique that redirects traffic from a failed or unreachable server to a healthy one, based on continuous health checks. It's one of the oldest and most widely used resilience mechanisms on the internet — and one of the most misunderstood, because DNS failover has real limits that no configuration can fully remove.
How DNS Failover Works
At a basic level, DNS failover replaces a static DNS answer with a dynamic one that depends on server health:
- Health checks continuously test an endpoint — via ICMP ping, HTTP/HTTPS request, or a TCP/UDP port check — to confirm it's actually serving traffic correctly, not just powered on.
- Failure detection logic decides when a health check failure counts as a real outage. Systems typically require multiple consecutive failures, or agreement across several monitoring locations, before triggering failover — a single failed check from one location is usually noise, not a real outage.
- DNS response update — once failure is confirmed, the authoritative DNS server stops returning the unhealthy IP and starts returning the backup instead.
When the primary endpoint recovers and passes health checks again, the system can automatically fail back — or wait for manual confirmation, depending on policy.
Why TTL Is the Real Constraint
TTL (Time To Live) tells DNS resolvers how long to cache an answer before asking again. This is the single biggest factor in how fast DNS failover actually works — and the one most people underestimate.
If your TTL is set to 3600 seconds (one hour), a resolver that cached the old, unhealthy IP won't ask again for up to an hour, no matter how fast your health checks detect the failure. For failover-enabled records, TTLs of 30 to 300 seconds are common practice, trading a small increase in query volume for dramatically faster propagation.
| TTL | Failover speed | Query load |
|---|---|---|
| 3600s (1 hour) | Slow — up to 1 hour for some clients | Low |
| 300s (5 min) | Moderate | Moderate |
| 30-60s | Fast | Higher, usually negligible for modern DNS infra |
Even with a low TTL, DNS failover is not instant. Some public resolvers don't strictly honor TTL and may hold answers longer, and some client-side caches (OS, browser) add their own delay. Low TTL reduces the failover window — it doesn't eliminate it.
DNS Failover vs. Load Balancing
These two get conflated constantly, but they solve different problems:
- Load balancing distributes traffic across multiple healthy endpoints simultaneously, during normal operation, to spread load and improve performance.
- DNS failover only activates in response to a failure — it doesn't do anything while all endpoints are healthy.
A load balancer sitting in front of your infrastructure makes per-request decisions instantly. DNS failover is coarser and slower by nature, because it depends on caching. The two aren't competitors — most resilient architectures use both, at different layers.
Active-Passive vs. Active-Active DNS Failover
- Active-passive: the primary record is returned under normal conditions. The passive backup only appears in DNS answers once the primary fails its health check. Simpler to reason about, no load distribution during normal operation.
- Active-active with weighted records: multiple endpoints are already receiving live traffic. Failover simply removes the unhealthy endpoint from the rotation — traffic that would have gone to it is redistributed among the remaining healthy ones.
Where DNS Failover Falls Short
DNS failover is a genuinely useful layer, but it has structural limits worth knowing before you rely on it as your only resilience mechanism:
- It's cached, so it's not real-time. No TTL setting makes DNS failover instantaneous for every client.
- It doesn't migrate active connections. DNS failover operates at the routing layer, not the connection layer — existing TCP connections to a now-unhealthy server aren't moved; only new lookups get the new answer.
- It has no visibility into partial degradation. A server can be technically reachable but returning errors or slow responses in ways a simple health check misses, unless checks validate the actual application response, not just connectivity.
- Flapping is a real risk. If health checks are too sensitive, a system can oscillate between primary and backup repeatedly, which is often worse for users than a single clean outage.
This is why DNS failover is best understood as one layer in a broader resilience strategy — not a replacement for a CDN-aware control plane that can make faster, application-level routing decisions across multiple providers.
The Bottom Line
DNS failover is effective, well-understood, and available almost everywhere — but it's bounded by caching behavior that no configuration fully removes, and it has no awareness of what's happening above the DNS layer. For teams whose resilience strategy depends entirely on DNS failover, a CDN-provider-side outage can still mean a slow, TTL-bound recovery rather than a fast one.
Continuuly operates above the DNS layer, as an out-of-band control plane that detects provider degradation and reroutes traffic across CDNs — without waiting on DNS propagation. See how it works →