Using zonec to avoid O(N^2) complexity

NSD
1

Hello,

I'm managing a number of zones that may well grow, so I've
been trying to avoid running the complete "rebuild" command.
It seems wasteful to me to do that for all zones if it is
known that only a single zone changed.

Specifically, when combined with OpenDNSSEC which regularly
reloads its N zones into the daemon, and if each reload takes
N rebuilds, then the order of complexity is N^2. And all
that could be overcome by being able to rebuild, import and
delete a single zone.

I've tried to use zonec for that purpose, but discovered that
this drops all other zones from the database. It can be read
into the man page though, in retrospect :wink:

Is there a reason why this N^2 complexity is there? With tens
of domains it is no problems, but what happens beyond thousands?

Thanks,
-Rick

2

I've had the same experience. I've been told that this will be improved
in NSD4.
Not only was a lot of time wasted reloading NSD, it also caused all
kinds of problems such hangs, crashes and missed updates. Mind you, most
of this experinece is based on the ancient NSD2, NSD3 might be better.
In the end I wrote a wrapper script to handle nameserver restarts (both
NSD and Unbound). If a zones is reloaded any further commands will be
queued until the rebuild is done. Than another 'rebuild' is issued to
import any changes that were made inbetween.
I've attached the script. The comments are in Dutch but I know you can
read that.
The first reload command gets executed directly.
The second command creates a waiting queue.
The third moves into the queue.
Then the Unbound-caches are flushed.

(attachments)

nameserver-reload (2.26 KB)

3

Hi Casper,

I've had the same experience. I've been told that this will be improved
in NSD4.

OK, I'm on NSD 3.2.10 by the way. Didn't mention it because the
suggestion was not related to any function (before 4, apparently).

Not only was a lot of time wasted reloading NSD, it also caused all
kinds of problems such hangs, crashes and missed updates.

And here I was thinking it was due to my multi-master mode use that
I experienced "nsdc stop" failures and "nsdc restart" blockages...

In the end I wrote a wrapper script to handle nameserver restarts (both
NSD and Unbound). If a zones is reloaded any further commands will be
queued until the rebuild is done. Than another 'rebuild' is issued to
import any changes that were made inbetween.

Surprising... I've seen references to locking in the nsdc scripts,
are these not included in NSD2?

I've attached the script. The comments are in Dutch but I know you can
read that.

Thanks for sharing. Sure, the rest of World is long overdue learning
our beautiful language anyway :wink:

Cheers,
-Rick

4

Nothing is as bad as bad documenation
The following might not be clear.

I've attached the script. The comments are in Dutch but I know you can
read that.
The first reload command gets executed directly.
The second command creates a waiting queue.
The third moves into the queue.

Over here the local (hidden master) NSD is restarted.
This master should notify all slaves, however sometimes notifies got
lost. Therefor I explicitly send an extra notify to our slaves (haar &
pade).