On Mon, Feb 01, 2010 at 07:07:49PM +0100, Matthieu Herrb wrote: > Hi, > > before trying to implement it, I'd like to seek opinions on the sanity > of the following: > > most resolver libs have quite long timeout on the DNS server they > query, and generally start again from the 1st one in their > configuration (typically /etc/resolv.conf) for each name resolution. > So when the 1st name server is down, the impact on client machines is > really noticeable and make users complain. > > So I would like to implement some kind of replication using carp to > ensure that the ip address listed in the client configuration will > always answer. > > First I'm making sure that this server is a recursive, caching only > name server. The authoritative server is separate, and for him the > multiple NS records (with one master and some slaves) works well. > > I'm using net/unbound to implement the server, but still I don't trust > it enough to consider that as long the interface on one machine > running unbound is up and getting carp advertisements the name server > is answering. So I'm considering to use ifstated to monitor the > unbound process and demote the interface if something goes wrong. > > Does this look sane ? > > If someone has already implemented something similar, I'd like to ear > about it (and may be to see sample ifstated.conf that implement it). > > Hint if someone wants to do the same: in unbound.conf you have to > explicitly set 'interface:' to the IP of your carp group (setting > outgoing-interface is not enough) , otherwise unbound will answer from > the IP of the carpdev interface. > > -- > Matthieu Herrb
This sounds sane, in the sense that I have proposed doing very similar setups in the past to avoid the exact problem your users are seeing. However, the only one I did manage to get permissions to implement was with a pair of commercial DNS applicances however. .... Ken
