DNS Failover Versus a Load Balancer: What Each One Actually Fixes

DNS failover changes which IP address a domain name resolves to, based on health checks against each candidate endpoint, so new connections get routed to a healthy region once the unhealthy one is detected. Its core limitation is caching: resolvers and clients cache a DNS answer for a duration you set, called the time to live, and any client holding an old cached answer will keep connecting to the dead endpoint until that cache expires, regardless of how fast your health check detected the failure. This is why a failover strategy that only changes DNS, without accounting for caching, tends to look instant on a status dashboard while still failing for a meaningful share of real users.

A load balancer sitting in front of multiple backend instances or regions can detect an unhealthy target and stop routing new traffic to it within seconds, without the client needing to do anything or re-resolve anything, since the client is only ever talking to the load balancer's own stable address. Its limitation is scope: a single load balancer typically operates within one region or one cloud provider's network, so it doesn't help when the failure is the load balancer's own region going dark entirely. Confirm which failure modes your specific load balancer setup actually covers before assuming it protects against a full regional event, since that assumption is exactly where the gap tends to hide.

DNS failover alone means every client is exposed to its own cache's stale answer for up to the full time-to-live window, which can be minutes, during exactly the period when fast failover matters most. Load balancer failover alone means you have no answer for a full regional outage that takes the load balancer itself down along with everything behind it. Neither one, used by itself, actually covers the full range of failures a production system needs to survive, and a failover plan built around only one of them will look complete right up until the specific failure it doesn't cover actually happens.

A quick decision rule helps here. For each failure you want to survive, ask whether it takes out a single instance or an entire region. A single instance is a load balancer problem, and its health checks should handle it within seconds. An entire region, including the load balancer itself, is a DNS problem, and recovery will be bounded by how long clients cache the old answer. For example, if a plan says a regional outage recovers in about a minute, check whether that number comes from the health check or from the time to live clients actually honor. Write the answer next to each failure mode in your runbook, so the expected recovery time reflects what users will experience rather than what a dashboard reports.

Use a load balancer within each region for fast, sub-second failover between instances in that region, and DNS failover across regions for the case where an entire region, including its load balancer, goes down. Keep the DNS time-to-live short enough that a real cross-region failover completes in a reasonable window, while accepting that it will never be as fast as the load balancer's own instant, in-region failover, because that's a fundamentally different mechanism with a fundamentally different floor on speed. Document which layer is expected to handle which class of failure, so an on-call engineer isn't left guessing mid-incident about why traffic hasn't shifted yet.

A failover plan that covers both layers usually includes these pieces:

• Run a load balancer inside each region, so unhealthy instances stop receiving new traffic within seconds and no client has to re-resolve DNS.
• Configure DNS failover across regions, backed by health checks, for the case where an entire region and its load balancer go dark.
• Set the DNS time to live low enough that a cross-region failover finishes in a window your business can tolerate, and lower it before an outage rather than during one.
• Write down which layer handles which class of failure, so an on-call engineer knows why traffic has or hasn't shifted yet.
• Run a failover drill and measure the recovery time clients actually experience, since cached DNS answers can outlast the configured value.

Say a company configures DNS failover with a lengthy default time-to-live left over from before anyone thought carefully about failover speed, then tests a regional outage and finds clients still hitting the dead region well after the health check correctly detected the failure and updated the DNS record. The health check worked. The DNS record updated. Cached resolvers around the internet simply hadn't caught up yet, because nothing about a health check can force a client's own DNS cache to expire early. Shortening the time-to-live ahead of time, before an outage, is the only real fix for this specific gap.