Dear list,
I'm a new nsd user. I want to replace a bind9 nameserver, which works as
a (bind) slave. I converted the named.conf, started nsd and tested with
zonecheck - everything seems okay.
Now I want to add additional slave zones to the server. But this works
only with stopping and starting the nsd process. None of the other
nsdc commands starts the zone transfer from the master.
What is wrong?
I'm using nsd 3.2.1 (Debian 4.0 amd64)
Best regards,
Thomas.
As far as I know, nsd can't add or remove zones while running. This was a
feature requested years ago, but I haven't seen any announcements of
progress on it.
This continues to be the main reason I haven't adopted nsd for production
use; I wasn't able to figure out a sane way to add or remove zones without
dropping queries. My nameservers handle thousands of domains, and something
gets added or removed regularly. I don't want authoritative nameserver
downtime every time I do a push. Am I missing something?
-- Aaron
that's right. Adding/removing zones only take effect after a complete
restart, not after a reload. I believe bind behaves similarly.
Paul
that's right. Adding/removing zones only take effect after a complete
restart, not after a reload. I believe bind behaves similarly.
Nope. You can use 'rndc reconfig' to add/remove zones from bind9.
Paul Wouters wrote:
that's right. Adding/removing zones only take effect after a complete
restart, not after a reload. I believe bind behaves similarly.
IIRC bind9 only needs an "rndc reconfig" to reload configuration and I
don't believe this makes it drop queries, but I might be wrong.. I sort
of only have one zone (and some tiny static ones)
I can indeed see why the feature mentioned is highly desirable for
service providers.
I'm a new nsd user. I want to replace a bind9 nameserver, which works as
a (bind) slave. I converted the named.conf, started nsd and tested with
zonecheck - everything seems okay.
Now I want to add additional slave zones to the server. But this works
only with stopping and starting the nsd process. None of the other
nsdc commands starts the zone transfer from the master.
What is wrong?
I'm using nsd 3.2.1 (Debian 4.0 amd64)that's right. Adding/removing zones only take effect after a complete
restart, not after a reload.
This is a big barrier for replacing bind with nsd! Is there any
chance to put this problem on the ToDo list?
I believe bind behaves similarly.
no, rndc reload|reconfig works fine!
Best regards,
Thomas.
Aaron Hopkins wrote:
Now I want to add additional slave zones to the server. But this works
only with stopping and starting the nsd process. None of the other
nsdc commands starts the zone transfer from the master.
What is wrong?As far as I know, nsd can't add or remove zones while running. This was a
feature requested years ago, but I haven't seen any announcements of
progress on it.
The reason for this is, is that it is required to re-read the
configuration file. The decision was to not read the configuration file
while running in order to minimalize security vulnerabilities.
No, not for almost forever now 
-- BIND-8 and newer will notice zones that have been added or removed from the configuration upon reload, regardless of whether they are primary or slave zones, and it does all the right things with NOTIFY, etc., IIRC.
It is too bad NSD will not yet do the same thing.
However, since DNS is a distributed service it's not critical that any individual nameserver remain operational 101% of the time. Don't be afraid to restart your authoritative nameservers! Just remember to stagger them a few minutes apart so that all the servers for a zone are not down at the same time. Of course if you operate all of the authoritative nameservers for any given zone then I really hope you've fully understood and implemented all of RFC 2182!
While I don't see any really pressing need to change this behaviour, I would be interested to learn of any real threats that have been identified here and what risk has been estimated.
The worst I can think is that even if nsd is running chrooted then an attacker could still easily force it to load an entirely different configuration. However I suspect the _additional_ risk there is rather low so long as all the code to read and parse said configuration remains in executable memory. Even then the additional risk is still relatively low since if the attacker can change executable memory enough (and perhaps more than once) then anything's possible.
The real question would be what could be gained by such a complex and more difficult attack -- if the attacker can alter the running code sufficiently, and their goal is to have the compromised program continue to answer DNS queries, then they can make it answer with anything they want without first having to find write-able filesystem space in which to store the new configuration and zone files and then having to make it jump through hoops to read those new files files.
Aaron Hopkins wrote:
As far as I know, nsd can't add or remove zones while running. This was a
feature requested years ago, but I haven't seen any announcements of
progress on it.The reason for this is, is that it is required to re-read the
configuration file. The decision was to not read the configuration file
while running in order to minimalize security vulnerabilities.
Can you provide some more detail here as to what security vulnerabilities
this helps against?
If I recall the design correctly, the nsd master process never processes DNS
queries, which makes it mostly immune to remote attacks. You already are
parsing the config as root to bind to the right interfaces, so you already
have to trust the config parser. Is the idea to not process nsdc requests
as root?
What if it would only re-parse zone: sections of the config without a
reload? Or zones could live in a seperate config file that was allowed to
be re-parsed, but could only contain zones?
My zone config is auto-generated and they all look exactly the same except
the zone name. I'd also be happy to just supply default options for zones
and let the zone compiler compile everything it finds in a particular
directory.
NSD is otherwise fully capable of handling the needs of service providers,
but not being able to add or remove zones without dropping queries is an
important omission, since it happens way more frequently than other uses of
NSD.
This continues to be the main reason I haven't adopted nsd for production
use; I wasn't able to figure out a sane way to add or remove zones without
dropping queries.
Is the expectation that adding and removing zones is infrequent enough that
dropping queries isn't a big deal? Or do you expect people to remove
servers from their load balancer/ECMP/anycast pool, reload, then add back?
-- Aaron
I was apparently too brief when making my comments. I hope to clarify it
in this e-mail.
Introducing a nsdc reconfig is lots of work that needs lots of error
handling methods. One could re-read the configuration file upon nsd
reload but it must also be communicated to the xfrd process. In the
design of NSD3, IPC communication is limited as much as possible, to
limit the issues of synchronization between these two processes. For
more details of these issues, I have to refer you to Wouter, the
original implementor of NSD3.
So, reconfig requires lots of complex code with respect to error
handling and process communication that is bug prone.
However, I sense that this is a hotly wanted feature, so we will
consider it.
Regards,
Matthijs
Matthijs Mekking wrote: