[nsd-users] nsd-control delzone on a zone that is defined in the nsd.conf

[Anand Buddhdev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/05/2013 17:05, Lukas Wunner wrote:

> I was already wondering why there are two implementations for the 
> same functionality now, given NSD's "lean and mean" credo. ;-)
> 
> Is the intention to drop the addzone/delzone workflow in favor of 
> reconfig? The latter is probably sufficient for 90% of the use
> cases (including ours) but it may be nice to keep the
> addzone/delzone workflow for very dynamic environments.

This addzone/delzone functionality has also been part of BIND for
quite some time now. However, I don't know of anyone who uses it. And
there's a good reason for it. If you operate several servers which all
need to have an identical configuration, then running addzone/delzone
on each is cumbersome. It is even more problematic if one of your
servers is unreachable for some reason. You need to build some kind of
transaction tracking to ensure that the addzone/delzone operations are
applied to that server when it is reachable again. Additionally, if
you want to add a new server to a cluster, you have to find a way to
bootstrap it with all the zones. In short, the whole process becomes
messy and error-prone.

In comparison, it is much easier to define your zones in nsd.conf (or
named.conf) and just push these files out, followed by an "nsd-control
reconfig" or "rndc reconfig". If a server is temporarily unreachable,
it's not a problem. When it comes back up, your config management
system (rsync, puppet, cfengine, ansible etc) can bring the nsd.conf
file up to date, and the server's configuration will become identical
to the others in the cluster. If you want to add a new server, you
just add it to your config management system, and it gets a copy of
the nsd.conf file, and its configuration is instantly the same as the
others in your cluster.

To summarise, the addzone/delzone feature is nice, but most operators
are unlikely to use it. If the addzone/delzone functionality were to
be removed, I would not mind at all.

Regards,
Anand
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlGU/6QACgkQi+U8Q0SwlCu/3QCfc5yOOtdXLyojRAaYrQKiADFX
sCAAn3covBk7csXyaHtFH2dhHC2gRkkO
=8jjr
-----END PGP SIGNATURE-----