Spring Fresh Sale! - Up To 67% OFF BDIX Hosting + Free Domain
DNS

DNS Failover and Health Checks: Staying Up When a Server Dies

DNS failover automatically stops sending traffic to a server that has failed, redirecting visitors to a healthy backup by changing the DNS answer. It relies on continuous health checks and short TTLs — and understanding its limits is as important as its benefits.

How it works

A monitoring system (usually run by your managed DNS provider) continuously checks whether your server is responding. While it is healthy, DNS returns its address. When the checks detect a failure, the provider updates the DNS answer to point at a backup server instead. Visitors follow the new answer once their cached record expires.

Health checks

The checks decide everything, so they should reflect real availability:

  • Check the right thing — ideally an application-level check (does the site actually respond correctly?), not just whether the IP pings.
  • Check often so failure is detected quickly.
  • Require multiple failures before failing over, to avoid flapping on a brief blip.

Why low TTLs are essential

Failover changes the DNS answer — but resolvers keep serving the old answer until its TTL expires. A record cached for an hour cannot be rerouted for up to an hour. Failover records therefore use very low TTLs (often 30–60 seconds), accepting extra query load for fast recovery.

The honest limitations

  • It is not instant — there is detection time plus TTL time before all users move.
  • Caching is imperfect — some resolvers ignore very low TTLs, so a few users linger on the old answer.
  • It reroutes, it does not fix — you still need a healthy backup to send traffic to.

For truly seamless failover, DNS is often combined with a load balancer or anycast, which reroutes at the network layer without waiting for DNS caches.

Frequently asked questions

How fast is DNS failover?

As fast as detection plus the record's TTL — so with 30–60 second TTLs and quick health checks, most users move within a minute or two. It is fast, but not truly instantaneous, because caches must expire.

Why do some users still hit the dead server after failover?

Because their resolver cached the old answer and may honour it until the TTL expires — and some resolvers enforce a minimum TTL, ignoring very low values. This tail is inherent to DNS-based failover.

Is DNS failover enough for high availability?

It helps a lot, but for seamless availability it is often paired with a load balancer or anycast that reroutes at the network layer instantly, without depending on DNS caches expiring.

Was this article helpful?