I have used tinydns for many many years now and it has always worked
very well. I like its simplicity: 1 text file is converted into a cdb
database, there's no master/slave environment (all nameservers are
equal) and synchronisation is done by rsync. Tinydns is run by runit, a
supervise system.
I'm looking at NSD now and I think I can use NSD the same way I use
tinydns. The only difference is the "one file contains it all" system,
but that's rather easy to script. Just rsync the zone files and send a
HUP to the supervisor. If a nameserver is not reachable it it will
autmagically synchronise.
Are there good reasons *not* to use nsd this way? This will not be a
1000000 queries per second system BTW.
I'm looking at NSD now and I think I can use NSD the same way I use
tinydns. The only difference is the "one file contains it all" system,
but that's rather easy to script. Just rsync the zone files and send a
HUP to the supervisor. If a nameserver is not reachable it it will
autmagically synchronise.
Are there good reasons *not* to use nsd this way? This will not be a
1000000 queries per second system BTW.
This is a perfectly reasonable way to use NSD. In fact, it is somewhat
better than using zone transfers between one NSD master and some slaves,
because NSD is only able to provide a full AXFR, but not an incremental
IXFR. So rsyncing the zones is probably the most efficient. As a side
effect, you don't need to arrange for NOTIFY between the servers, nor
any kind of XFR ACLs or TSIG keys.
Ok, thnx. I'm busy now to "sed" the tinydns format to nsd format. Is
there somehow a way to tell nsd to use 1 file for all zones? NSD will
only read these files when it receives a HUP or a restart and converts
it to a db format. Now I need to add a domain in two places: 1) the
zone file itself and 2) an include in the config file containing:
If you're going to be adding and removing zones on the fly, you can do
that with NSD. You can either add/remove zones in the nsd.conf file, and
reload NSD, or use "addzone" and "delzone" with nsd-control.
I do not receive my own posts, I also get "needs moderator approval"
although I received a welcome to this mailinglist. Must be something
wrong somewhere...
> only read these files when it receives a HUP or a restart and
> converts it to a db format. Now I need to add a domain in two
> places: 1) the
The DB format is optional, and in fact, not recommended these days.
Just set:
database: ""
in your nsd.conf, and NSD will not build a database file. It will just
read zones into memory and serve from there.
I use the default /var/lib/nsd/nsd.db, that's what I meant with db, just
"database".
> zone file itself and 2) an include in the config file containing:
>
> zone:
> name: "example1.com"
> zonefile: "com/example1/zone"
> zone:
> name: "example2.com"
> zonefile: "com/example2/zone"
>
> That needs more scripting and I'm lazy
Yeah, but you just need to do this once, right?
Yep, that's true, but I'm too lazy sometimes
If you're going to be adding and removing zones on the fly, you can do
that with NSD. You can either add/remove zones in the nsd.conf file,
and reload NSD, or use "addzone" and "delzone" with nsd-control.
I just had a glance at nsd-control it and indeed, I think it is nicer to
invoke an "nsd-control reconfig" instead of telling the supervisor to
restart nsd.
OTOH, nsd does not read its config file when receiving a HUP. It would
be a nice if a USR2 would force a config reload in case of a supervised
setup. Maybe that's something for the wishlist.
database: <filename>
By default /var/lib/nsd/nsd.db' is used. The specified file is used to
store the compiled zone information. Same as commandline option -f. If
set to "" then no database is used. This uses less memory but zone
updates are not (immediately) spooled to disk.
So, in case of a supervised version and rsynced zone files it is not a
problem to set it to "". But the database is indexed I suppose. NSD is
serving a few hundred domains and the database is just a few megabytes
big. There must be some or other threshold to use a database or not.
What would be the advice in this particular case?
database: <filename>
By default /var/lib/nsd/nsd.db' is used. The specified file is used to
store the compiled zone information. Same as commandline option -f. If
set to "" then no database is used. This uses less memory but zone
updates are not (immediately) spooled to disk.
So, in case of a supervised version and rsynced zone files it is not a
problem to set it to "". But the database is indexed I suppose. NSD is
Correct. Just set it to "", and this will prevent NSD from building a
database out of the plain text zone files. It will just read the zone
files into memory and answer queries out of that.
When you change your zone files, just send the main process a SIGHUP or
use "nsd-control reload". They are equivalent.
serving a few hundred domains and the database is just a few megabytes
big. There must be some or other threshold to use a database or not.
What would be the advice in this particular case?
Yes, the database is indexed and has some pre-compiled answers. However,
for low query volumes, there is no difference. In fact, the database
adds complexity that you don't need/want. The developers of NSD
themselves have acknowledged that the database isn't needed, and
recommend turning it off.
Well, NSD *does* re-read its config file on SIGHUP. However, it only
reapplies those config elements that it can, such as addition or removal
of zones. Other elements, such as the listening address and port, number
of workers (essentially all the elements in the "server" section) cannot
be changed on the fly, so NSD just ignores them. If you change any of
those, you have to restart NSD.
This confuses many users. It would be nice if the developers could
indicate in the nsd.conf man page, which option requires a restart to
take effect, and which one can be adjusted with a "reload" or "reconfig".
The problem is (was) that I used "include:" statements in nsd.conf
to load zone information. Apparently nsd does not reread the include
files upon a SIGHUP. I scripted everything into 1 file and a HUP
rereads the zone info now.
It is rather intended to be used with patterns. You configure a pattern in your configuration, then you tell nsd via nsd-control addzone to use a specific pattern for a specific zone. nsd keeps track of these assignments in a file usually in “/var/lib/nsd/zone.list” (configurable via “zonelistfile”).
Zones can be added/removed pretty dynamically that way. What nsd does internally when receiving the addzone/delzone I haven’t cared about so far.
On the config in general:
“server-count” should be set to the number of CPUs of the respective machine. And, if you have this set to more than 1 and run it on Linux, you might also want to consider setting “reuseport” to “yes”. I have more experience with this option from a high performance unbound system, but activating this option helped improve performance by a margin of 30-40%. I think it has a similar impact on nsd when a high amount of requests has to be served.
It is rather intended to be used with patterns. You configure a
pattern in your configuration, then you tell nsd via nsd-control
addzone to use a specific pattern for a specific zone. nsd keeps
track of these assignments in a file usually in
"/var/lib/nsd/zone.list" (configurable via "zonelistfile").
Zones can be added/removed pretty dynamically that way. What nsd does
internally when receiving the addzone/delzone I haven't cared about
so far.
I'm not yet familiar with these patterns and the manpage is only
comprehensible when you already understand it Anyway, I just tried a
"nsd-control reconfig" and that rereads the zone file into memory.
But I'll have a look at it tomorrow. It's time for a beer over here
On the config in general:
"server-count" should be set to the number of CPUs of the respective
machine. And, if you have this set to more than 1 and run it on
Linux, you might also want to consider setting "reuseport" to "yes".
I have more experience with this option from a high performance
unbound system, but activating this option helped improve performance
by a margin of 30-40%. I think it has a similar impact on nsd when a
high amount of requests has to be served.
This is a low level system with only a few hundred domains. I think one
CPU will be sufficient.
It works A simple script containing "nsd-control reload" and
"nsd-control reconfig" does the job. Simple and effective. I switched
from tinydns to nsd a few hours ago and everything seems to work well.
