DNS Failover for Website Redundancy: Setup and Configuration Steps

This article is a localized edition of the Japanese original. Read the Japanese original

DNS failover is a mechanism in which the DNS service regularly monitors whether your servers are alive and, when the main server stops responding, switches to returning the IP address of a standby server. It gives you redundancy without placing a load balancer, but the switch takes as long as the DNS cache lasts. This article explains the mechanism and its limits, how to create a health check, how to prepare the standby server, and how to test the switch, using a WordPress site as the example.

How DNS failover works, and how it differs from round robin

Ordinary DNS just returns the registered records as they are, and does not notice if a server is down. With DNS failover, a "health check" is added on the authoritative DNS service side.

1. The DNS service connects to the main server at regular intervals, for example over HTTP(S), and checks whether a normal response comes back
2. If it fails a set number of times in a row, it judges the main server to be "unhealthy"
3. For subsequent queries, it returns the IP address of the standby server
4. When the main server recovers, it goes back to the original response, depending on your settings

"DNS round robin," which lines up several A records and distributes among them, is meant for load balancing and does not monitor whether servers are alive. It keeps returning the IP of a stopped server too, so it is insufficient as a means of redundancy. Failover aims to "return only healthy servers," and the most common setup is an active/standby configuration of one main server plus one standby server.

Estimate how long the switch takes

The first thing to understand about DNS failover is that the switch does not finish instantly. The downtime that users see is roughly the sum of the following.

• Detection time: check interval x number of failures before it is judged unhealthy (example: 3 failures at 30-second intervals is about 90 seconds)
• Remaining cache time: how long resolvers keep the old answer (at most the TTL)
• Retention on the client side: how long browsers and apps reuse name resolution results, and how long they keep using existing connections

The shorter the TTL, the faster the switch, but the number of queries increases. It is common to set the records subject to failover to about 60 to 300 seconds. However, some resolvers and applications (such as runtimes with their own DNS cache) do not honor the TTL and hold the answer longer, so even with a 60-second TTL, not everyone switches within 60 seconds. This is a method to choose on the premise that "downtime of a few minutes is acceptable." If you need a switch within seconds, consider a load balancer or a cloud redundancy setup.

Main services that support DNS failover

Health checks and failover are provided as features of authoritative DNS services. Representative ones are as follows (as of October 2026). The scope, names, and pricing of the features may be changed by each company, so check the official documentation.

• Amazon Route 53: You create a health check, choose "Failover" as the routing policy of the record, and specify primary and secondary.
• Cloudflare: DNS itself has no health monitoring; you set up origin pools, monitors, and failover order with the paid Load Balancing feature.
• Azure Traffic Manager / Google Cloud DNS routing policies / NS1 and others: They can switch responses based on priority and health checks.

The free DNS that comes with a registrar, or BIND run as is, does not have this feature. You can write your own monitoring script and rewrite records through an API, but it does not work if the monitoring script itself stops, so using a managed service first is safer.

Step 1: Prepare a URL for the health check

If you monitor the top page as is, page caching can make it judged "healthy" even when the database is down. On WordPress, preparing a lightweight URL that checks whether the connection reaches the database improves the accuracy of the judgment.

<?php
// health-check.php (example placed in the WordPress root, at the same level as wp-load.php)
// Load only the minimum with SHORTINIT, query the DB, and return the result
define( 'SHORTINIT', true );
require __DIR__ . '/wp-load.php';

global $wpdb;
$ok = ( '1' === (string) $wpdb->get_var( 'SELECT 1' ) );

header( 'Cache-Control: no-store' );
header( 'Content-Type: text/plain; charset=utf-8' );
http_response_code( $ok ? 200 : 503 );
echo $ok ? 'OK' : 'NG';

When you define SHORTINIT, processing stops at the database connection without loading plugins or themes, so you can keep the load of monitoring low. If it cannot connect to the database, WordPress returns an error, so the monitoring side judges it unhealthy.

Points to check after you place it are as follows.

• Exclude it from page caching (caching plugins, CDN, and server cache). If a cached 200 keeps being returned, the monitoring is meaningless
• Do not output error details or version information
• If monitoring is done over HTTPS, check that it does not fail because of certificate validation or redirects

On the monitoring side, requiring that this URL return 200 and that the body contain "OK" reduces false judgments (whether you can set a string-match condition depends on the service).

Step 2: Prepare a standby server

The hardest part of failover is the contents of the standby server rather than the DNS settings. For WordPress, decide first on one of the following two approaches.

Approach A: Show an apology or maintenance page: Make the standby a server that returns only a static page, or object storage plus a CDN. No data synchronization is needed, and the setup is simple. If the goal is that "the site does not go blank when it stops," this is enough.

Approach B: Show the same site on the standby as well: You need database replication, synchronization of wp-content/uploads, and matching theme and plugin files. Writes are what to watch out for. If the standby also accepts comments, orders, and updates in the admin screen, the data will diverge from the main side when you switch back. Prepare one of the following in advance: make the standby read-only, stop write processing, or decide a data merge procedure for switching back.

With either approach, the standby server needs an SSL certificate for the same domain. Because no traffic normally reaches the standby, renewal with Let's Encrypt HTTP-01 validation tends to fail. Keep the standby's certificate valid by methods such as issuing it with DNS-01 validation, or distributing the certificate obtained on the main side in a safe way.

Step 3: Configure the DNS records and health check

Taking Route 53 as an example, the flow is as follows (the wording on screen may change as the console is revised).

1. Create a health check for the main server (specify the protocol, hostname, path /health-check.php, check interval, and number of failures before it is judged unhealthy)
2. Create two A records with the same name (example: www.example.com) and set the routing policy to failover
3. Make the first one the primary and associate it with the main IP and the health check from Step 1, and make the second one the secondary and specify the standby IP
4. Set the TTL to about 60 to 300 seconds

When you use Cloudflare's Load Balancing, the idea is to register the main and the standby each as a "pool," attach monitoring settings, and fail over by pool priority.

When you rebuild an existing record for failover, shorten the existing record's TTL by the day before the work, and export and back up the current DNS settings before you start; this makes it easier to roll back if a problem occurs.

Step 4: Test the switch and the switch back

It is dangerous to configure it and then wait for a real outage. During hours with few users, deliberately make the main server unhealthy and check the behavior.

# 1. Check the normal response (the main IP is returned)
dig +short www.example.com A

# 2. Reproduce a failure, for example by returning 503 only for the health check URL on the main side, or by stopping the web server

# 3. Query the authoritative DNS directly and check that it changed to the standby IP
dig +short www.example.com A @ns-xxx.awsdns-xx.com

# 4. Also check through a public resolver (it may still show the old IP until the cache expires)
dig www.example.com A @8.8.8.8

The time until the authoritative DNS response changes is the detection time, and the extra time until it changes on the public resolver is the effect of the cache. If you record the times you measured, they become a basis for judging "how many more minutes until it switches" during an outage.

Also check switching back (the action of returning to the original after the main server recovers). If it switches back automatically while the main server is still unstable, "flapping," where it repeatedly switches over and back, occurs. If there were writes on the standby under Approach B, it is safer to operate so that it does not switch back automatically, and you switch back manually after checking the data.

Also check the redundancy of the name servers themselves

Even if you make the web servers redundant, if the domain's authoritative DNS stops, names cannot be resolved. Check whether multiple name servers are registered and whether they are spread across different networks.

dig +short example.com NS

Managed DNS normally assigns multiple name servers distributed across multiple locations. If you use your own DNS servers, put at least two in different networks, or consider using a secondary DNS service.

Summary

• DNS failover is a mechanism that returns the standby server's IP when a health check detects a problem, and its purpose differs from round robin.
• Switch time is the sum of "detection time + DNS cache + client retention," so use it on the premise that it takes minutes.
• On WordPress, create a health check URL that verifies the database, and exclude it from caching.
• Decide first whether the standby server is an "apology page" or "the same site," and if it is the same site, prepare for how writes and switching back are handled and how the SSL certificate is renewed.
• After setting it up, deliberately cause a failure and measure the switch and switch-back times.

• How to think about DNS TTL settings and how to change them
• Building a WordPress load balancer with HAProxy

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)