[dns-operations] Best practices for Linux/UNIX stub resolver failover

Todd Lyons tlyons at ivenue.com
Tue Apr 22 19:25:03 UTC 2014

On Tue, Apr 22, 2014 at 12:04 PM, Chuck Anderson <cra at wpi.edu> wrote:
> Is it really expected that the first DNS server listed in
> /etc/resolv.conf should never go down?  Operationally speaking, who


> can actually rely on listing multiple nameservers in /etc/resolv.conf
> and using libc's failover mechanism in any kind of production server?
> Because the failover behavior in libc is atrocious--each new or
> existing process has to re-do the failover after timing out, and even
> long-running processes have to call res_init() to re-read resolv.conf.
> It seems that the only sensible way to run a datacenter (or a network
> full of Linux workstations for that matter) is to either:
> 1. Make sure the first nameserver listed in resolv.conf never goes
>    down by using Anycast DNS or some other failover mechanism like
>    VRRP or CARP on the DNS server side.

[root at site03 ~]# more /etc/resolv.conf
search example.net
options rotate timeout:2

> What do the DNS experts say about best practices for DNS failover in
> the stub resolver?

I'm curious to see what they think here too.


The total budget at all receivers for solving senders' problems is $0.
 If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine

More information about the dns-operations mailing list