When a server IP suddenly becomes unreachable, manually updating DNS records is slow and error-prone. Configuring automatic DNS failover ensures your domain can automatically "find" a healthy server. Below, we guide you step-by-step—from underlying principles to practical implementation—on how to set up a reliable automatic failover system.
What problems does automatic DNS failover solve?
If the primary server goes down or its IP changes while DNS records still point to the old address, user access will fail. The core logic of automatic failover is to continuously monitor server health; once an anomaly is detected, the system automatically updates DNS records via the provider's API to redirect traffic to a backup address.
There are two common trigger scenarios: server failure (downtime, network interruption) and passive IP address changes (dynamic IPs, data center adjustments). The former requires a health check mechanism, while the latter requires IP detection and reporting mechanisms.
Choosing a Solution: Check Your DNS Provider's Capabilities
There are two technical approaches to automatic DNS failover; the right choice depends on your DNS provider.
Approach 1: Built-in failover features. The provider's managed DNS service natively supports health checks and failover policies. You simply configure health check rules and address pools (primary/backup) in the dashboard, and the platform handles the rest automatically.
Approach 2: Script-based API calls. If your DNS provider does not offer native failover (e.g., Cloudflare Free tier, DNSPod), you need a script to periodically monitor server status and call the API to update DNS records when an issue is detected.
Script-based API Calls (Using Cloudflare as an Example)
Cloudflare's free tier does not offer native failover, so a script is required. `jinqians/cloudflare_dns` is a mature solution that supports automatic failover between primary and backup VPS instances and works correctly even when the Cloudflare proxy (the "orange cloud") is enabled.
Step 1: Obtain a Cloudflare API Token. Log in to the Cloudflare Dashboard, go to "My Profile → API Tokens," and create a token. Select only the `Zone:Zone:Read` and `Zone:DNS:Edit` permissions to adhere to the principle of least privilege.
Step 2: Obtain the Zone ID and Record ID. Use the API to retrieve the Zone ID for your domain and the Record ID for the specific DNS record you need to modify.
Step 3: Deploy the script. Download the script to the server and grant it execution permissions:
wget https://raw.githubusercontent.com/jinqians/cloudflare_dns/refs/heads/main/dns_switch.sh
chmod +x dns_switch.shStep 4: Run the configuration wizard. Execute `./dns_switch.sh`; the script will guide you to input information such as the API Token, Zone ID, Record ID, IP addresses and ports for the primary and backup VPS, as well as the health check port and HTTP path.
Step 5: Set up a scheduled task. Add a cron job using `crontab -e`; it is recommended to run the check every 5 minutes:
*/5 * * * * /path/to/dns_switch.sh >> /var/log/dns_switch.log 2>&1The script performs health checks based on TCP ports and HTTP status codes. It automatically switches DNS resolution to the backup VPS if the primary VPS fails and can send notifications via Telegram when the IP changes.
Pure DDNS Scenario (Passive IP changes, server remains healthy)
If your scenario involves a server that stays online but has a changing public IP (e.g., dynamic broadband IP or data center adjustments), you do not need failover logic—only DDNS (Dynamic DNS) is required. This involves periodically checking the local public IP and calling the API to update the DNS record whenever a change is detected.
`ddns-go` is currently the most recommended lightweight solution, deployed as a single binary file.
Step 1: Install `ddns-go`. Download the binary file for your platform or use Docker for one-click deployment.
Step 2: Configure the DNS provider. In the `ddns-go` web management interface, select your DNS provider and enter your API credentials. For Cloudflare, for example, you need to provide the API Token and domain information.
Step 3: Set the check interval. By default, it checks for public IP changes every 5 minutes. Upon detecting a change, it automatically calls the API to update the DNS record. A TTL of 60 seconds is recommended to ensure network-wide cache updates within one minute.
If you need to manage multiple domains or multiple DNS providers simultaneously, `NewFuture/DDNS` offers a more comprehensive feature set. It supports IPv4/IPv6 dual-stack, multiple configuration files, and automatic creation of missing DNS records; it relies solely on the Python standard library, ensuring excellent compatibility. Key Configuration Considerations
The TTL setting represents a balance between failover speed and resolution stability. A shorter TTL allows for faster failover but increases DNS query volume. For production environments, a TTL of 30–60 seconds is recommended; this ensures rapid switching without placing an excessive load on the DNS resolution system.
Health checks require "hysteresis" logic. Failover should not be triggered by a single failed probe, as network jitter can lead to false positives. In script-based solutions, require multiple consecutive failures before executing a switch; in GTM solutions, configure probe intervals and failure thresholds to prevent "route flapping."
Verify that the DNS update has actually taken effect after the switch. Global propagation of DNS cache updates takes time; use tools like `dig` or online services to query from multiple geographic locations and confirm that the new DNS records have propagated.
A backup strategy is equally important. Automated failover relies on the continuous operation of the underlying script or platform. If the server hosting the script goes down, the failover logic will fail as well. It is recommended to deploy the failover script on an independent machine that does not rely on the server being monitored.
Jtti Provides Stable Infrastructure for Automated Failover
Regardless of the solution you choose, the stability of the primary server is your first line of defense. If the server experiences frequent downtime, even the best failover mechanism becomes merely a reactive measure—constantly "fighting fires."
Jtti’s cloud server solutions provide the infrastructure stability needed to support these systems. Our Hong Kong and US nodes utilize premium CN2 GIA lines with optimized direct connectivity across major carriers, maintaining a packet loss rate below 0.1% even during peak evening hours; this minimizes the risk of "false failure" triggers caused by network link fluctuations. All plans come with dedicated bandwidth as standard, eliminating service outages caused by "noisy neighbors" competing for bandwidth. Our "same-price renewal" policy ensures predictable long-term operating costs.
