<div dir="ltr">Wow. Great new feature! Thanks for the explanation.<div><br></div><div style>Regards,</div><div style>Will Pressly</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 14, 2013 at 1:44 AM, W.C.A. Wijngaards <span dir="ltr"><<a href="mailto:wouter@nlnetlabs.nl" target="_blank">wouter@nlnetlabs.nl</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div>Hi,<br>
<div class="im"><br>
On 05/14/2013 10:24 AM, Will Pressly wrote:<br>
> Hi Wouter,<br>
><br>
> Thanks for the reply.<br>
><br>
> Wow. that sounds really great if I am understanding you correctly.<br>
> so, if I change my nsd.conf with any kind of arbitrary additions<br>
> and deletions, a simple nsd-control reconfig will intelligently<br>
> and dynamically merge all of those changes -- effectively obviating<br>
> the need for nsd-control [add|del]zone?<br>
<br>
</div>Yes, it picks up changes and applies them by reforking the server<br>
processes.  This is limited to zone, key, pattern, access-control<br>
lists changes.  The server config is not really changeable without a<br>
restart (because it needs root privileges, which have been dropped).<br>
Also RRL config ratelimits and whitelists are updated (if you use RRL).<br>
<br>
It provides another workflow, not control add|del zone, but push<br>
nsd.conf and reconfig.<br>
<br>
Best regards,<br>
   Wouter<br>
<div class="im"><br>
> Thanks, Will<br>
><br>
><br>
> On Tue, May 14, 2013 at 12:01 AM, W.C.A. Wijngaards<br>
</div><div><div class="h5">> <<a href="mailto:wouter@nlnetlabs.nl">wouter@nlnetlabs.nl</a> <mailto:<a href="mailto:wouter@nlnetlabs.nl">wouter@nlnetlabs.nl</a>>> wrote:<br>
><br>
> Hi Will,<br>
><br>
> On 05/08/2013 11:32 PM, Jaap Akkerhuis wrote:<br>
><br>
>> I am trying to wrap my head around the rationale of the<br>
>> restriction on not allowing nsd-control to delzone a zone that is<br>
>> configured in the nsd.conf. What is the risk here? Is it more of<br>
>> an operational one where it will not truly delete if a stop/start<br>
>> of the daemon occurs without modification of the nsd.conf? I<br>
>> mean, if your workflow is to always update your nsd.conf by<br>
>> removing entries for zones you are planning to delzone (and then<br>
>> blowing away the zone.list file before start) -- then where is<br>
>> the problem, exactly?<br>
><br>
>> I see the restriction only exists in remote.c, and it doesn't<br>
>> look like deleting one of these zones declared in the nsd.conf<br>
>> would be much different that one that wasn't (although I am<br>
>> probably missing something).<br>
><br>
>> Can you help me understand this, please?<br>
><br>
>> FYI, Wouter is on vacation so it might take another week or so<br>
>> before he answers. What I do remember from talking about this is<br>
>> that "nsd-control delzone" is merely the inverse of "nsd-control<br>
>> addzone".<br>
><br>
>> Zones defined in nsd.conf are supposed to be static that is why<br>
>> the man nsd-control says:<br>
><br>
>> Zones  configured  inside  nsd.conf  itself  cannot be removed<br>
>> this way because  the  daemon  does  not  write to the nsd.conf<br>
>> file, you need to add such zones to the zonelist file to be able<br>
>> to delete them with the delzone command.<br>
><br>
>> Hope this helps.<br>
><br>
> Yes, what you can do, if you modify the nsd.conf yourself, is that<br>
> you modify the nsd.conf and then nsd-control reconfig (you need<br>
> that latest svn trunk of NSD4 for that, beta4 does not have this<br>
> feature). Then it adds and removes the changes you made in the<br>
> config file. This may fit better into your existing workflow.<br>
><br>
> Best regards, Wouter<br>
><br>
><br>
><br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.13 (GNU/Linux)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
</div></div>iQIcBAEBAgAGBQJRkflkAAoJEJ9vHC1+BF+NLfsP/Aqn2c67ds/87+pnzux0UN+6<br>
+Rb4iNreUIGF0gY3gH3hM1m0zFazQLnhXBP6d+RJZ9Dmh44RoljIFVw6J20glmCR<br>
7keZmq01zr/W+JQ1+uoxj5Kv737OXkLL/CNF8+qIHx/O1/betvt7qdF8G2PL0qDX<br>
wAL53xTRnZ5MZKi0jX9sukxcj9tonBa6QIde6YxH6i2Joxg96U5R/jO/QQ0Ml5Kd<br>
ia8peN4oJZ39/M6zmiX9pcsqXXuWdv2RMMq12w570vS0jXziLIxz+KYZoh/T4saN<br>
Awi9LIT3zkwfb1u54DN43SIzbXfx4pZGYkhfk0kbeWZy4KeH5Wmr8qx1fEATCGmF<br>
GvtFRCaBR6vIf01Tj63v272EVyVtH/RLF7XWQ8JHJYx/35ZvuONopiZtMl4UeGz2<br>
887MopB4IHNqDddIR/Adal0HoVPxuZTqAzNbZ6pN/dxr2W45cPO0A1ym590oY4HO<br>
gngQRBGLc3DEIKPFjQtetFreG2llepQtPlmu7idNAaNN7Bg+H62VPKdGDIGuYUw8<br>
YmlgjjfnovEaNocIz3Q7bt84gZe24mkxe6KLA5BGMbJaI0nmbcrh7udMte2nLxSZ<br>
vAkIebpe6ZMiGjUzGN5kHxSFmxOgE45PdexQTnI2KGTpYjsrOjeaHedGWPDzsDqS<br>
jnpmcAgp53M1AOZFvKqY<br>
=2WOw<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div>