DNS failover is a technique that automatically changes DNS records to redirect traffic from a primary server to a backup server when the primary becomes unavailable. When monitoring detects that the primary server is down, not responding to health checks, returning errors, or experiencing degraded performance, the DNS records pointing to it are automatically updated to point to the backup instead. Visitors who were going to the primary are now routed to the backup without any manual intervention.

The name describes the mechanism, DNS is used as the failover layer. Rather than requiring hardware load balancers, complex routing infrastructure, or manual intervention to redirect traffic during an outage, DNS failover uses the DNS system itself as the switching mechanism. When the primary fails the DNS record switches. When the primary recovers the DNS record switches back.

DNS failover is a fundamental availability technique for websites, APIs, and internet services that need to maintain uptime through server failures, data centre outages, maintenance windows, and other disruptions. It is the DNS-native approach to ensuring that a service remains accessible even when individual components fail, complementing other availability mechanisms like load balancing, geographic redundancy, and content delivery networks.

How DNS failover works

DNS failover requires three components working together, health monitoring, DNS record management, and the DNS infrastructure that propagates record changes.

Health monitoring: a monitoring system continuously checks whether the primary server is healthy and reachable. Health checks vary in sophistication from simple TCP connection tests to full application-level checks, verifying that the server responds to HTTP requests with the correct status codes, that database queries complete successfully, that specific API endpoints return valid responses. The monitoring frequency determines how quickly a failure is detected, checks every 30 seconds detect failures faster than checks every five minutes.

Failure detection: when the monitoring system determines the primary server is unhealthy, failed health checks exceed a configured threshold, it triggers the failover action. Thresholds prevent false positives from transient failures, a single failed health check does not immediately trigger failover. Multiple consecutive failures confirm a genuine outage before the switch is made.

DNS record update: when failover is triggered the DNS record management system updates the relevant DNS records, typically A records or CNAME records: replacing the primary server’s IP address with the backup server’s IP address. The update is made on the authoritative nameserver immediately. Resolvers that query the authoritative nameserver after the update receive the backup server’s address.

DNS propagation: the updated DNS records propagate to recursive resolvers worldwide as their cached copies of the old records expire. The propagation speed depends on the DNS TTL set on the records. New visitors, those whose resolvers have updated, reach the backup server. Existing visitors with cached records may continue attempting to reach the primary until their cache expires.

Recovery: when monitoring detects the primary server has recovered, health checks pass again for a configured number of consecutive checks, the DNS records are updated back to point to the primary. Traffic gradually shifts back to the primary as resolver caches update. The failover is complete.

DNS TTL and failover speed

The DNS TTL on failover-relevant records is the most critical configuration parameter for DNS failover effectiveness. TTL determines how quickly traffic shifts to the backup server after a failure is detected and DNS records are updated.

High TTL, slow failover: a record with TTL 86400, 24 hours, is cached by resolvers for up to 24 hours. When the primary fails and DNS records are updated to point to the backup many resolvers continue serving the old record pointing to the failed primary for up to 24 hours. New visitors who resolved the domain during this period are directed to the backup. Existing cached results direct visitors to the failed primary for up to the full TTL duration.

Low TTL, fast failover: a record with TTL 60, one minute, is cached by resolvers for only one minute. When the primary fails and DNS records are updated most resolvers fetch the updated record within one minute. New visitors are quickly directed to the backup. The failover is effectively complete within minutes for most resolvers.

The failover TTL trade-off: very low TTLs, 30 to 60 seconds, provide fast failover but increase DNS query volume significantly. Every resolver worldwide queries the authoritative nameserver frequently, every minute, for the protected records. For high-traffic domains this generates enormous query volumes that authoritative nameserver infrastructure must handle. Managed DNS providers with robust infrastructure handle this well. Self-hosted nameservers may struggle with the increased load.

Practical TTL values for failover: DNS failover implementations commonly use TTLs of 60 to 300 seconds for failover-protected records. This balances failover speed, shifting traffic to the backup within one to five minutes of DNS record update, against manageable query volume. Some implementations use ultra-low TTLs of 30 seconds or less for mission-critical services where even two to five minutes of availability impact is unacceptable.

Pre-failure TTL lowering: some DNS failover strategies use higher TTLs during normal operation, reducing query volume when everything is healthy, and automatically lower the TTL when a potential failure is detected before the full failover is triggered. This provides the efficiency of high TTLs during stable operation and the speed of low TTLs when failover may be needed.

Types of DNS failover

DNS failover implementations vary in sophistication from simple active-passive configurations to complex multi-region routing.

Active-passive failover: the simplest DNS failover configuration. The primary server handles all traffic during normal operation. The backup server is idle, or handling other traffic, ready to take over when needed. When the primary fails DNS records switch to the backup. When the primary recovers DNS records switch back. Clean and simple, but the backup server capacity is wasted during normal operation when it is not serving traffic.

Active-active with failover: both primary and backup servers handle traffic simultaneously during normal operation, traffic is distributed between them through load balancing. When one server fails all traffic shifts to the remaining server through DNS failover. This uses server capacity more efficiently, both servers are productive during normal operation, and provides failover protection simultaneously.

Geographic failover: DNS records point to servers in different geographic regions. When the primary region becomes unavailable DNS failover routes traffic to a server in a different region. Geographic failover protects against regional outages, data centre failures, regional network problems, natural disasters, that might take down an entire region simultaneously.

Cascading failover: a hierarchy of failover targets. If the primary fails traffic moves to the secondary. If the secondary also fails traffic moves to the tertiary. Cascading failover provides multiple layers of redundancy for services that require extremely high availability.

Weighted failover: DNS records include weight information that determines what proportion of traffic goes to each server. During normal operation the primary receives most traffic, perhaps 90 percent, and the backup receives a small portion to verify it is working correctly. When the primary fails the weight shifts to 100 percent to the backup. Weighted failover eliminates cold-start issues on the backup server, since it has been continuously handling a small portion of traffic it is warmed up and ready to handle full load immediately.

DNS failover vs load balancing

DNS failover and DNS load balancing are related techniques that are often confused or conflated. They serve different purposes and are often used together.

DNS load balancing: distributes traffic across multiple servers simultaneously during normal operation. Multiple DNS records for the same domain name, multiple A records, cause resolvers to receive different IP addresses in response to the same query. Traffic is distributed across the servers through round-robin or weighted distribution. Load balancing optimises resource utilisation and improves throughput. It does not inherently provide failover, if one server fails some visitors continue being directed to the failed server by resolvers that cached its IP address.

DNS failover: redirects traffic from a failed server to a working backup. Requires health monitoring and automated DNS record changes. Does not distribute load during normal operation in a pure active-passive configuration, one server handles all traffic. Provides availability protection rather than throughput optimisation.

Combined load balancing and failover: the most robust configuration. Multiple servers handle traffic through load balancing during normal operation. Health monitoring watches each server. When a server fails health-check-aware DNS removes it from the rotation, routing all traffic to the remaining healthy servers. This provides both the throughput benefits of load balancing and the availability benefits of failover.

Intelligent DNS platforms, Route 53, Cloudflare, NS1, and others, support health-check-aware routing that combines load balancing and failover. Records are weighted or distributed across multiple servers. Unhealthy servers are automatically removed from DNS responses. Healthy servers handle increased load until the failed server recovers.

DNS failover and redirect management

DNS failover intersects with redirect management in specific scenarios where redirect infrastructure must remain available through failures.

Failover for redirect infrastructure: a domain connected to redirect management infrastructure depends on that infrastructure being available. If the redirect platform experiences an outage visitors receive errors rather than being redirected correctly. DNS failover can protect redirect infrastructure by switching to backup redirect infrastructure when the primary is unavailable, ensuring visitors continue to be redirected even during platform outages.

Redirect as failover destination: DNS failover can use a redirect as the failover destination. When the primary application server becomes unavailable the DNS failover switches to a simple redirect server, or a managed redirect service, that redirects all visitors to a maintenance page, a status page, or an alternative version of the service. The redirect itself does not serve the full application but it provides a meaningful response rather than connection errors.

TTL management for redirect domains: domains used primarily for domain parking or simple redirects can use low TTLs without the high query volume concern that affects application servers. A parked domain receiving modest traffic with a low TTL for rapid failover adds minimal load to authoritative nameservers. Low TTLs are particularly practical for redirect-only domains.

Maintenance redirects with DNS failover: planned maintenance can be handled through DNS failover mechanisms rather than, or in addition to, 503 responses. When maintenance begins the DNS failover switches traffic to a maintenance holding server that serves an appropriate maintenance page. When maintenance ends the DNS failover switches back to the primary. This is more proactive than relying on the application to return appropriate status codes during maintenance.

Implementing DNS failover

DNS failover requires infrastructure at two levels, health monitoring and DNS management, that work together.

Managed DNS providers with health check support: the simplest implementation uses a managed DNS provider that supports health checks and automatic failover natively. AWS Route 53, Cloudflare, NS1, Dyn, and other managed DNS providers offer health-check-aware routing, configure the primary and backup records alongside health check parameters and the provider handles monitoring and record switching automatically.

Route 53 health checks monitor endpoints via HTTP, HTTPS, or TCP at configurable intervals. When health checks fail Route 53 automatically removes the unhealthy record from DNS responses and returns only healthy records. When the endpoint recovers it is re-added automatically.

Cloudflare Load Balancing provides similar functionality, health checks monitor origins and traffic is routed only to healthy origins. Cloudflare’s global network performs the health checks from multiple locations reducing false positives from single-location monitoring.

Third-party DNS failover services: standalone DNS failover services monitor endpoints and update DNS records at the domain’s DNS provider through the provider’s API when failures are detected. These work with any DNS provider that offers an API, not just providers with native health check support.

Custom monitoring and API integration: organisations with specific requirements implement custom health monitoring systems that trigger DNS record updates through their DNS provider’s API when failures are detected. This requires more development effort but allows complete control over monitoring logic, failover thresholds, and record management behaviour.

Health check configuration

The health check configuration determines how accurately and quickly failures are detected. Poorly configured health checks cause false positive failovers, unnecessarily switching to the backup during transient issues, or false negatives, failing to switch when the primary is genuinely unavailable.

Check type: the protocol and endpoint used for health checks. TCP checks verify that a port is reachable, fast and simple but do not verify application functionality. HTTP/HTTPS checks verify that an endpoint returns the expected response code and optionally specific content, more meaningful but require the full application stack to be functioning.

Check interval: how frequently health checks run. More frequent checks, every 10 to 30 seconds, detect failures faster. Less frequent checks, every five minutes, reduce monitoring load but slow failure detection. The check interval determines the minimum time from failure to detection.

Failure threshold: how many consecutive failed checks trigger failover. A threshold of one check causes immediate failover on any failure, fast response but prone to false positives from transient network issues. A threshold of three checks requires three consecutive failures before triggering, reduces false positives but adds delay equal to three check intervals.

Recovery threshold: how many consecutive successful checks trigger recovery and switch back to the primary. A recovery threshold prevents premature recovery when the primary is intermittently available, ensuring it is genuinely stable before traffic returns.

Check location: where health checks originate. Single-location checks may detect local network issues as failures when the primary server is actually fine. Multi-location checks, from multiple geographic regions, distinguish genuine server failures from local network problems. Managed DNS providers with health check support typically run checks from multiple global locations.

Limitations of DNS failover

DNS failover is a powerful technique but has inherent limitations that must be understood to use it appropriately.

Propagation delay: even with very low TTLs DNS failover does not provide instant traffic switching. Resolvers with cached records continue directing visitors to the failed primary until their cache expires. During the propagation window, potentially minutes even with low TTLs, some visitors receive errors from the failed primary while others reach the backup successfully. For applications requiring sub-second failover DNS is not the appropriate layer, load balancers and anycast routing provide faster switching.

Cached results at client level: browsers and operating systems cache DNS results independently of resolver caches. Even after a resolver updates its cache individual clients may continue using cached results for the browser cache duration, typically shorter than the TTL but variable. This creates an additional delay layer beyond resolver propagation.

Existing connections unaffected: DNS failover only affects new DNS lookups. Visitors with active connections to the primary server are not redirected by a DNS change. Their existing connections continue until they disconnect and reconnect, at which point their resolver may have the updated record and direct them to the backup.

False positive failovers: aggressive health check thresholds trigger unnecessary failovers during transient issues, a momentary network blip, a health check timeout that does not reflect genuine application failure. Unnecessary failovers disrupt users and may shift traffic to backup infrastructure that is less capable than the primary.