How to modify "A" records on the slave when master is down?

Chris Buxton cbuxton at
Wed Dec 3 18:47:12 UTC 2008

On Fri, 2008-11-21 at 21:10 -0800, stevehunter_1 at wrote:
> Hello.  I have two geographically different datacenters.  Each
> datacenter has two instances of BIND.
> There is one master out of these four.  The zones will have multiple
> "A" records (pointing to the two datacenters to provide some minimal
> amount of redundancy and load balancing)
> What I want to do is put together a plan for when the master either
> fails or the master becomes unavailable.
> So if your master fails, or more likely, it becomes unavailable, and I
> need to change the "A" records on the other slaves, how do you do it?
> Can I have a master in each datacenter and a slave in each datacenter,
> but a change made to any master propagates to all slaves?  For that
> matter, can I just have four masters and be done with it?
> It doesnt make sense that I could have multiple masters.. but I have
> no idea how to solve this problem.  If datacenter A goes down for
> three days, i want to be able to modify the slave "A" records to stop
> pointing to the bad datacenter.  And when the datacenter comes back up
> and the old master is alive, I want everything to work.

You can always promote a slave to master status, or maintain a DR copy
of the zone.

Configure your slave servers to look to your second master (or the slave
that will be promoted as needed) as a second master, and enable
multi-master. Like this:

zone "" {
	type slave;
	file "zone.file";
	masters {
	multi-master yes;

If you have a backup (or DR) master, then the slaves will switch to its
version of the zone automatically. If you instead use a slave that will
be promoted for this purpose, then, when disaster strikes:

- Promote the slave (edit the zone statement, changing the type and
removing the 'masters' and 'multi-master' statements).
- Edit the zone as needed.
- 'rndc reconfig' ought to work, but you may need 'rndc reload' instead.

If you have lots of zones, it makes sense to keep a whole separate
named.conf instead, and simply switch over to it.

Chris Buxton
Men & Mice

More information about the bind-users mailing list