[nsd-users] How to add new zones to the slave on NSD 4.0

[Johan Ihrén]

Hi Stephane,

On 27 Feb 2014, at 16:02 , Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:

> On Thu, Feb 27, 2014 at 03:41:03PM +0100,
> Johan Ihrén <johani at johani.org> wrote 
> a message of 73 lines which said:
> 
>> nsd-control -s $master addzone $zone mpattern
>> nsd-control -s $slave  addzone $zone spattern
> 
> Note this solution is not atomic: if the network has a glitch, you may
> end up with the zone configured on the master and not on the slave.

Sure. That's why I said "basically". In a more real implementation you would have to add verification of whether the different operations succeeded or not and what to do if they did not(*).

But that is needed regardless, i.e. if there was control magic between the master and the slave, where changes on the master triggers changes on the slave, then the same possibility of a network glitch exists. And has to be dealt with.

Wouter wrote:
> The zonelist files are plain text and (if the server is stopped) can
> be synced/diffed/copied.
> 
> It is also possible to add it to (an include file of) the config file.
> And then nsd-control -s $server -c $server.keys.conf reconfig.

Exactly. And this is basically what we do at present for part of our operations, i.e. generate new configs, verify correctness, distribute new configs in dependable way, ask servers to re-read configs in the right order.

I maintain my position that this type of problem is better dealt with outside the actual nameservers. We have a distributed infrastructure, network glitches are a fact of life, no control magic can remove that fact and then I'd rather have to deal with it explicitly than have it hidden under the hood as magic control goop that may or may not do the right thing if there's a serious outage.

Regards,

Johan Ihrén

(*) I see that if I try to add the same zone twice I get the error:

error could not add zonelist entry

While it is good to get an error in this situation I think it would be useful to be able to distinguish between things like "could not add because zone with that exact config is already there", "could not add because zone with *different* config (i.e. other pattern) is already there", "could not add because of an error writing to disk", etc.

I.e. at present if I wanted to improve on my trivial script I admit that I'm not entirely sure how to construct the actual test for whether the addzone command completed or not. And this is yet another reason that we do this outside of our nameservers, because then we have full control over the integrity of the propagation of updated configurations.

Another thing that struck me is that if I was to use "addzone" in production I'd really appreciate a "nsd-control testzone foo.example." command which should return the config entry from the zonelist file. Then verification of propagation would become much easier.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20140227/d5e0cb31/attachment.bin>