nsupdate in a high-availability configuration

[Kevin Darcy]

The update clients shouldn't be using resolv.conf to determine where to
send a Dynamic Update. They should be using the SOA and NS records of
the zone they're trying to update.

In theory, I believe the following would work: set the SOA MNAME to a
name which resolves to the address of the master and one or more
registered slaves, under normal circumstances this means that updates
may sometimes go to slaves instead of to the master, but that's okay
because the slaves will just forward them to the master; when the master
fails, reconfigure one of the slaves as the master, this should be
totally transparent to the update clients.

Unfortunately, update forwarding is broken in BIND 8. But this scheme
should work in BIND 9.


- Kevin

jacob at mayhem.com wrote:

> I'm attempting to set up a highly-available Solaris-based system
> that will accept DNS updates from a set of NT clients.  nsupdate
> from the NT BIND port works fine, however, what do I do when the
> master server goes down?  I'm currently running BIND 8.2.2-P5
> on the servers, but that's not too hard to change if need be.
>
> I have a slave server on the same LAN which may well be running
> some sort of clustering software eventually; should I look at
> doing something like having the clustering software detect that
> the master server has gone down, and trigger a script to
> reconfigure the slave server into a master server?  Once that's
> done, if the NT clients have their resolv.conf listing both
> nameservers, will the updates get sent to the second listed
> server if the first server is down?
>
> I'd like to hear about any experiences or plans anyone has with
> providing not just DNS resolution services, but update services
> as well in a high-uptime-required environment.
>
> --
> Jacob DeGlopper, FF/EMT-B, N3RHI
> jacob at mayhem.com