When your servers are in different data centres or with different providers, a shared floating IP is not possible. DNS failover solves this by changing which IP a hostname points to when a health check detects that the primary server is down.
Before you start
- Two servers able to serve the same site or service, with data kept in sync (database replication, file sync).
- A DNS provider that offers health checks and failover records, or a monitoring tool that can update DNS by API.
- Background: high availability basics.
How DNS failover works
- The DNS provider checks the primary server (HTTP, HTTPS or TCP) every few seconds or minutes from several locations.
- While healthy, the record (e.g.
www) returns the primary IP. - After a set number of failed checks, the provider returns the secondary IP instead.
- When the primary recovers, records switch back (automatically or manually).
TTL matters
Resolvers cache answers for the record's TTL. Use a low TTL such as 60–300 seconds on failover records, so clients pick up the change quickly. Some resolvers and browsers cache longer, so a small share of users may hit the dead server for a while.
Set it up
- Prepare the standby server and confirm it can serve traffic on its own IP (test with a
hostsfile entry). - In your DNS provider, create a health check for the primary (e.g.
https://203.0.113.10/healthwith the right Host header). - Create failover records: primary pointing to 203.0.113.10, secondary to 198.51.100.20, linked to the health check.
- Lower TTL and add alerts so you know when failover happens.
- Test by stopping the web server on the primary and watching resolution with
dig +short www.example.com.
Compared with other approaches
| DNS failover | Floating IP | Load balancer | |
|---|---|---|---|
| Across providers/regions | Yes | No (same L2 network) | Global LBs only |
| Switch time | Seconds to minutes plus caching | Seconds | Seconds |
| Complexity | Low | Medium | Medium–high |
For same-network failover see keepalived floating IP.
Limits and pitfalls
- Data consistency is your job: if the standby has stale data, users see old content or lose writes.
- Email (MX) failover works differently; MX records already support priorities.
- Health checks must test something meaningful (an endpoint that checks the database), not just that port 80 is open.
Frequently asked questions
Can I do active-active with DNS?
Yes, by returning multiple A records or using geo/latency routing, combined with health checks.
Does Cloudflare proxying change this?
When proxied, the CDN connects to your origins and can use its own load balancing features; see Cloudflare with cPanel.
Is DNS failover enough for a small site?
Often, good backups and quick restore are simpler. Failover makes sense when downtime is costly.