Multi-master (HA)

[Phil Mayers]

On 06/05/2014 19:39, Evan Hunt wrote:

> I don't want to influence the conversation here by saying too much about
> the ideas we've had so far, but I wanted to say: if anyone has specific
> thoughts on how to make this sort of thing easier in BIND -- even just at
> the level of "boy, it irritates me that I can't make BIND do <X>" --
> such comments will fall on welcoming ears.

If you want a bind slave to be capable of becoming a master with no 
dependencies - other than a valid copy of the zone data and the 
existing, on-box configs - you basically munge the config file. It might 
be nice if that were easier, especially for large files with lots of 
zones. Maybe there should be:

zone-template "foo" {
   masters ...
   filename "zones/$name/file";
   key-directory "keys/$name";
};
zone "bar" {
   zone-template foo;
};

An extreme version of that is: it might be nice if the config *were* a 
zone, updatable locally via nsupdate, slaved from the "primary" during 
normal operations. Suitable design of the schema for that zone could 
make it a very useful feature generally (think "subscribe to 
service-set"), and would avoid the need for everyone who does this to 
hand-roll rsync/perl scripts to manage bind.

I could expand on the idea if people don't think it's too insane ;o) I 
suspect it has all kinds of caveats I haven't thought of, however.

Obviously for sites with SQL DBs driving zone & contents, and already 
replicated out to or near your offsite slaves then you're basically 
there already. But there are reasons why you might not want to do that; 
in particular it might leak more information that the minimum DNS zone 
contents, to a machine you have less control over.

At a more basic level, the difference in default file format 
necessitates either conversion during change from slave to master - I 
assert this is undesirable as this is very likely happening in a hurry, 
possibly even with junior staff or semi-automated systems doing the work 
- or planning ahead to ensure the format is consistent everywhere (as we 
did). Something to note at very least. Maybe this could be made a bit 
more robust by detecting on-disk format and going ahead, rather than 
renaming it out of the way or failing to start?

DNSSEC keys are a tricky one; we tar/gpg/scp to the offsite slave. 
Obviously not an option with an HSM.