nsd users - May 2013 - nsd-control delzone on a zone that is defined in the nsd.conf

Hello All,

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?

Thanks!
Will Pressly
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20130507/5668e4ee/attachment.htm>

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.

	jaap

Hi,

On Tue, May 14, 2013 at 10:44:20AM +0200, W.C.A. Wijngaards
wrote:
> 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.

Best regards,

Lukas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 479 bytes
Desc: not available
URL:
<http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20130516/b9df2b60/attachment.bin>