-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Jan-Piet,
On 02/01/2013 07:28 PM, Jan-Piet Mens wrote:> Hello,
>
> I asked recently on the mailing-list of <a different DNS server>
> :) about adding zones on the fly, and it occurs to me that I have
> exactly the same questions about `nsd-control addzone|delzone`.
>
> I'd appreciate if you could help me clarify a few things, please.
>
> 1. Is NSD 'deaf' during an `addzone'? I don't think so, but
I'm
> finding it hard to determine definitely. I'm primarily concerned
> with NSD being able to handle any NOTIFYs it gets.
Normal Port 53 service continues.
The xfrd process handles the 'addzone' command *entry* in a blocking
manner (and becomes 'deaf' while the command text line is
transferred). Because that is simpler to implement. This is normally
not a time consuming task, simply the transfer of the line of text,
and the source is an SSL-trusted process (the SSL handshake itself is
performed in a non-blocking manner for this reason).
The work, of a long zone transfer, or of a large file read, is
performed by a separate process, so that normal service continues
while this work is performed. In this way, NSD should not be 'deaf'
while a (large) zone is added.
> 2. When I `addzone' a slave zone, NSD immediately picks that up,
> transfers the zone and creates the specified file. However,
> `delzone', while it drops the zone from NSD, does not remove the
> zone file from the file system. Is that a bug or was that
> implemented intentionally?
Yes this is intentional. If you delete the zone from configuration,
you may want to reconsider, and loss of data is very serious. It does
immediately delete the zone data from the nsd.db.
> It seems a bit illogical to me that the zone file isn't removed
> from the file system: what NSD creates it can remove. :-)
For slave zones, you can set zonefile: "" and then there is no
zonefile. Also not while it is added, the data is kept in nsd.db.
Is it desirable to delete the zonefile when delzone is executed? The
current implementation is based on the assumption that fat-fingers and
data-loss are a bigger problem.
> 3. If I direct `addzone|delzone' at the same NSD instance from
> multiple processes (on differing source IP address), is there any
> danger of the zonelist file being corrupted? Would there be a
> locking issue?
There is no locking issue. (You must not edit the zonelist file by
hand while NSD is running, that would create a locking issue.). High
volume of addzone and delzone requests may, if it starts to overwhelm
the daemon, create a backlog of these requests. What this (by design)
should result in, is that the requests are handled in larger batches.
Normally, addzone and delzone are immediate, but if overwhelmed, you
may have to wait for a whole batch of them to appear. Normal service
should continue while a separate process struggles to add the
processes, although the zone transfer handling process may also be
overwhelmed (become CPU-bound or disk-bound) by the incoming requests
(just the action of listening to the addzone requests and editing the
zonelist file) and zone transfers may slow down.
Best regards,
Wouter
> Thanks for clarification.
>
> Regards,
>
> -JP _______________________________________________ nsd-users
> mailing list nsd-users at NLnetLabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/nsd-users
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRD3BfAAoJEJ9vHC1+BF+NLBYP/jj4xJaoVpf9fSCk06SzeHTc
gbaVHRem0q2jkq/RnlBFhvOgIhtJG3xoFKhVsgnJDryQiz2+CxuDEc+Z2zdFJ0Aj
F1U0p+cX2/5HEBAnLiBpQuXd4nJYTAmv2l2X99mbH8MSqfD1prfxhyGPeB55aKpC
Mh+90+0qkxmS6VvSsb8OZ7ECtoRd6zY5eGkBUuQWMsPorfZ880ZXvXchDIdJStAm
SBlDXX/YC/oa6JexJjtonw1F1wK+dIfBnlydMCz8I3aoyCn6XnuM9cYPUtXW3xJR
6VdEXb3TbxfoVKOsPwXQykxKp5EiO+4gfKW+5mSxzYG6/gun/OQ+wdKOJZhX7yLQ
sM5eGGm3LVbtZHncUc+lsqP/OvlC+B4NYF0UAYfP2vR4HUMOQCYtoOCrP2Y+3QB4
ha0U2/YKTTwVxJBcdc+0uEMmaF8HuMBwDTzaBNXYt7i5C3b5orlyf0vOMMFRy32g
tbIgxHqCfzvj/4gRSmR6buwwTydiPimezCRdqJcDbaCNSwu4NzsJpUQmAJINWFMy
Jq/+rHaXqbkJ3v11JfiG+t6Z4BSXa9h7jjumsuNzZBdbYif4s4VVYRqkhnTen3an
ixXKC6Qw2lC+ZaBt8pyVcBH11QGozEij7fvv0FafVoBca5TtX2mekbxfTVMvNY3i
AbcKDXwruHbubiWudpDc
=8qze
-----END PGP SIGNATURE-----