DNS Failover — Automatic Traffic Redirection for Reliability

DNS failover is a mechanism that automatically redirects traffic away from failed servers. When a server becomes unreachable, the DNS provider detects the failure and stops returning that server's IP address. Incoming traffic is redirected to healthy servers instead.

Without DNS failover, a server crash means your website or service becomes unavailable until someone manually updates the DNS records. For a business website, every minute of downtime costs money. DNS failover automates the recovery process and reduces downtime from hours to minutes.

How DNS Failover Works

DNS failover requires health monitoring. The DNS provider continuously checks each server's status at regular intervals. The check method varies by provider. The simplest checks ping the server to see if it responds. More sophisticated checks attempt to establish a TCP connection on a specific port, like port 80 for a web server or port 443 for HTTPS.

HTTP health checks are the most useful. The DNS provider sends an HTTP request to a specific path on your server, like /health or /status. The server must respond with a successful HTTP status code (200-399) within a specified timeout. If the server responds with a 500 error or does not respond at all, the health check fails.

When a health check fails, the provider marks that server as unhealthy. It stops including that server's IP in DNS responses and routes traffic to the remaining healthy servers. The failed server continues to be monitored and is automatically restored when it starts responding to health checks again.

DNS Failover Recovery Time

DNS failover is not instant. The total recovery time is the sum of the health check interval, the failure detection threshold, and the DNS TTL. If you check every 30 seconds, require 2 consecutive failures (60 seconds), and have a 60-second TTL, the worst-case failover time is about 2 minutes.

Some providers offer faster detection using real-time monitoring and API callbacks. Instead of polling, your server can notify the DNS provider immediately when it detects a problem. This reduces the detection time to seconds. However, the DNS TTL still introduces delay because resolvers cache the old response.

For sub-second failover, DNS is not the right tool. You need a load balancer with active health checking and instant connection rerouting. DNS failover handles the larger scale recovery and works alongside load balancers for comprehensive protection.

Active-Passive vs Active-Active Failover

In active-passive failover, you have one primary server handling all traffic and one or more standby servers that remain idle. When the primary fails, DNS redirects traffic to a passive server. This is simpler to configure but wastes resources because the standby servers sit idle.

In active-active failover, all servers handle traffic simultaneously. When one server fails, its share of the traffic is distributed among the remaining servers. This is more efficient because you use all your resources all the time. The downside is that each server needs enough capacity to absorb the extra load when another server fails.

Most DNS failover setups use active-active because it is more cost-effective and provides better performance during normal operation. Active-passive is reserved for disaster recovery scenarios where the primary and secondary sites are in completely different geographic regions.

DNS Failover Providers

Cloudflare's load balancing service includes health monitoring and automatic failover. You configure origin pools within a region, and Cloudflare routes traffic to healthy origins. The free plan includes basic health checks. Paid plans add more monitoring regions and advanced features.

AWS Route 53 offers DNS failover through health checks and routing policies. You create a health check for each server endpoint, then configure failover routing records. Route 53 supports both active-active and active-passive configurations. The health checks can monitor endpoints directly or use CloudWatch alarms.

DNS Made Easy includes failover with all their DNS hosting plans. Their monitoring checks several locations simultaneously to avoid false failovers caused by regional network issues. DNS Made Easy also provides detailed reporting on failover events and server recovery.

NS1 offers the most sophisticated DNS failover with their filtering and routing engine. You can create complex rules that consider multiple metrics — server health, geographic location, performance data, and business rules — when deciding where to route traffic. NS1 is the best choice for enterprises with complex failover requirements.

Avoiding False Failovers

False failovers happen when a health check incorrectly marks a healthy server as failed. This causes unnecessary traffic shifts and can make the situation worse. Common causes include network hiccups, DNS provider monitoring nodes that cannot reach your server due to routing issues, and health checks that are too strict.

Mitigate false failovers by monitoring from multiple locations. If the DNS provider checks from 5 locations and only 1 reports failure, the server is probably fine. Most providers mark a server as unhealthy only when a majority of monitoring locations report failure.

Set appropriate failure thresholds. Requiring 2 or 3 consecutive failures before triggering a failover prevents brief network glitches from causing unnecessary redirects. The trade-off is slightly longer detection time when a genuine failure occurs.

Design your health check endpoint carefully. A health check that queries a database or external service can fail when those dependencies have problems, even if the server itself is healthy. The health check should verify that the server can handle requests, not that every dependency is functional. For more on high-availability DNS strategies, see our managed DNS guide.