Fail over using DNS / Bind 4.9.7-1 (QID 2855)

[Kevin Darcy]

Cricket Liu wrote:

> > So there is not "Easy" way to do with within DNS.  Could it be done in
> > conjuction with Net::DNS in perl or any of the c routines
>
> Yes, absolutely.  You could use Net::DNS or the C res_update() routine
> to monitor your main server and replace the A RR pointing to it with an
> A RR pointing to your backup if it fails.
>
> I've done this in Perl with Net::DNS, and it's simple.

Hmmm... And then you'd lower the TTL, I assume, to defeat the effect of
caching? Or just point all of the client resolvers at authoritative name
servers, presumably all having NOTIFY capability? And there'd also be
something to automatically "fall-forward" when the primary database server
comes back up again? Or would fall-forward be a manual operation?

I think this might be a good fit for the original poster's scenario -- he
specifically said that the failover should only occur if the primary
database server is *down*. It might not be such a good fit to deal with
connectivity problems, e.g. the primary database server is up but part of
the intranet can't get to it; you probably wouldn't want clients fighting
over the A record in that case (although a smart enough heartbeat monitor
might be able to distinguish reliably between a machine-down and a network
problem). These are reasons why I generally tend to view failover as
something best done in the client application/resolver, if it can't be done
completely transparently (as in e.g. Local Director or a shared-IP
server-clustering solution).

Another, really gross solution that occurred to me: master a DNS zone on
the primary database server itself, consisting solely of a generic name for
the database service. Make the TTL really low. Have no slaves. When the
primary database server goes down, no-one can resolve the name -- the
queries will time out. Then configure the clients with a fallback naming
service, e.g. "hosts" file, NIS, whatever. Put the same name there,
resolving to the address of the secondary database server. I'm not
recommending this AT ALL. It just goes into the "more than one way to skin
a cat" category...


- Kevin