IP Failover / Round robin DNS

How can I setup DNS so that I have failover dns?

For example:

mail.mydomain.com points to if its up, otherwise

(If you get the idea?)

4 Replies

There is no such thing as failover DNS. You can configure some sort of monitoring server to change your DNS records if a box goes down, but that will still take time to propagate, even with a low TTL.

The closest thing to what you describe is round-robin, but that isn't failover; you'll still be handing out the downed IP to a certain percentage of users.

You could combine the two approaches to mitigate impact; if you have five servers in round-robin and one goes down, and you have a sufficiently short TTL, then instead of 100% of customers having to wait for propagation, only 20% will have to wait.

If this is really for mail, as your example hostname indicates, you should look into multiple MX records. You can add as many as you want with a priority so your mail will go to the backup server if the first one is done.


The closest thing to what you describe is round-robin, but that isn't failover; you'll still be handing out the downed IP to a certain percentage of users.
Right, round-robin is more about load sharing than failover.

Of course, DNS itself can return multiple addresses for a single host, so another option is just to put multiple A records in DNS. In that case clients (at least most of them) will automatically try each address in turn, so while the first address may be bad, there will be failover to the latter addresses which can work. This has its own downsides through. First, depending on how the first address fails, it could take a significant timeout (30+ seconds) to try the next address. Second, technically such a DNS response indicates any of the addresses are valid, so a client could randomly choose an entry if it so desired, though I'm not sure any mainstream clients ever do this.

For mail though, as pointed out in jsr's response, MX records are absolutely the way to go - it's what they're designed for. Multiple A records also work, but MX records avoid their ambiguity in terms of precedence.

In the non-mail case, getting even more complex, but just for completeness, Linode offers another possibility which is to enable a single address for use on more than one Linode (the IP failover configuration on the network tab of Linode Manager). Then clients still use a single address from DNS but it hits the other box. But it's up to you to figure out when to activate that address on the backup box, so you have to setup some sort of inter-box monitoring on your own or a package that provides for it.

– David


mail.mydomain.com points to if its up, otherwise
DNS is not designed for failover. It can do load-sharing, but failover isn't a job for DNS. Use the right tool for the right job and it will work out much better for you.

The normal way to do this is to setup your 2 servers on the same local network and use 3 IP addresses:

.1 - Server 1

.2 - Server 2

.3 - Failover IP

Your DNS will point to .3 which is normally assigned to Server 1 (so it has 2 IP addresses). You use something like keepalived on both servers to monitor each other. If the keepalive daemon finds a fault, then server 1 will relinquish the .3 IP address and Server 2 will take it over.

The other way is to put another server in front of Server 1 and Server 2 which automatically routes incoming traffic to whichever server it detects as being available. This still has a single point of failure though so not really High Availability.

NB: as others have pointed out, if this is for incoming SMTP mail, then MX records are the correct solution. I'm assuming this is either for POP or Webmail etc access to your mail system and giving a different answer to those who have mentioned about the MX :P


Please enter an answer

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct