Hi Jan-Piet,
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