I am trying to wrap my head around the rationale of the restriction on not allowing nsd-control to delzone a zone that is configured in the nsd.conf. What is the risk here? Is it more of an operational one where it will not truly delete if a stop/start of the daemon occurs without modification of the nsd.conf? I mean, if your workflow is to always update your nsd.conf by removing entries for zones you are planning to delzone (and then blowing away the zone.list file before start) – then where is the problem, exactly?
I see the restriction only exists in remote.c, and it doesn’t look like deleting one of these zones declared in the nsd.conf would be much different that one that wasn’t (although I am probably missing something).
I am trying to wrap my head around the rationale of the restriction on not
allowing nsd-control to delzone a zone that is configured in the nsd.conf.
What is the risk here? Is it more of an operational one where it will not
truly delete if a stop/start of the daemon occurs without modification of
the nsd.conf? I mean, if your workflow is to always update your nsd.conf by
removing entries for zones you are planning to delzone (and then blowing
away the zone.list file before start) -- then where is the problem,
exactly?
I see the restriction only exists in remote.c, and it doesn't look like
deleting one of these zones declared in the nsd.conf would be much
different that one that wasn't (although I am probably missing something).
Can you help me understand this, please?
FYI, Wouter is on vacation so it might take another week or so
before he answers. What I do remember from talking about this is
that "nsd-control delzone" is merely the inverse of "nsd-control
addzone".
Zones defined in nsd.conf are supposed to be static that is why the
man nsd-control says:
Zones configured inside nsd.conf itself cannot be
removed this way because the daemon does not write to
the nsd.conf file, you need to add such zones to the
zonelist file to be able to delete them with the delzone
command.
I am trying to wrap my head around the rationale of the restriction
on not allowing nsd-control to delzone a zone that is configured in
the nsd.conf. What is the risk here? Is it more of an operational
one where it will not truly delete if a stop/start of the daemon
occurs without modification of the nsd.conf? I mean, if your
workflow is to always update your nsd.conf by removing entries for
zones you are planning to delzone (and then blowing away the
zone.list file before start) -- then where is the problem,
exactly?
I see the restriction only exists in remote.c, and it doesn't look
like deleting one of these zones declared in the nsd.conf would be
much different that one that wasn't (although I am probably missing
something).
Can you help me understand this, please?
FYI, Wouter is on vacation so it might take another week or so
before he answers. What I do remember from talking about this is
that "nsd-control delzone" is merely the inverse of "nsd-control
addzone".
Zones defined in nsd.conf are supposed to be static that is why
the man nsd-control says:
Zones configured inside nsd.conf itself cannot be removed this
way because the daemon does not write to the nsd.conf file,
you need to add such zones to the zonelist file to be able to
delete them with the delzone command.
Hope this helps.
Yes, what you can do, if you modify the nsd.conf yourself, is that you
modify the nsd.conf and then nsd-control reconfig (you need that
latest svn trunk of NSD4 for that, beta4 does not have this feature).
Then it adds and removes the changes you made in the config file.
This may fit better into your existing workflow.
Wow. that sounds really great if I am understanding you correctly. so, if I change my nsd.conf with any kind of arbitrary additions and deletions, a simple nsd-control reconfig will intelligently and dynamically merge all of those changes – effectively obviating the need for nsd-control [add|del]zone?
Wow. that sounds really great if I am understanding you correctly.
so, if I change my nsd.conf with any kind of arbitrary additions
and deletions, a simple nsd-control reconfig will intelligently
and dynamically merge all of those changes -- effectively obviating
the need for nsd-control [add|del]zone?
Yes, it picks up changes and applies them by reforking the server
processes. This is limited to zone, key, pattern, access-control
lists changes. The server config is not really changeable without a
restart (because it needs root privileges, which have been dropped).
Also RRL config ratelimits and whitelists are updated (if you use RRL).
It provides another workflow, not control add|del zone, but push
nsd.conf and reconfig.
For NSD4, the pid in the pidfile stays the same (because that process
stays). This is the zone transfer process that also handles nsd-control
connections.
It provides another workflow, not control add|del zone, but push
nsd.conf and reconfig.
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.
