On Tue, Feb 2, 2010 at 7:16 AM, Kenneth R Westerback <kwesterb...@rogers.com> wrote: > 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 > >
One thing I can suggest is a sort of transparent layer between the DNS servers and your clients that relays the request to each one simultaneously, and returns the first answer it gets. It's a possibility. -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
