[nsd-users] nsd as bind slave (xfer problem)

[Aaron Hopkins]

On Tue, 17 Feb 2009, Matthijs Mekking wrote:
> 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