NSD 4 migration and features

December 18, 2012 by wouter

This post describes migration to NSD4 and the new features of NSD4. An overview of the NSD 4 project is here.


The old NSD3 config file can be used without changes for NSD4. There are new config statements and some old statements are gone (and ignored by NSD4).

The nsd.db file has a new format that allows read and write. Thus the nsd.db file needs to be re-created in NSD4 format. This takes place when you start NSD4 the first time; it creates the nsd.db file. NSD4 needs write permission on the nsd.db directory for that. If you need to rollback to NSD3, run the old zonec to recreate the NSD3 nsd.db file (use nsdc rebuild).

The cron job for nsdc patch is no longer needed, because nsd.db is updated on-the-fly. It can be removed.

If you favor cron jobs, you can have a cron job that does “nsd-control write”. This would periodically write the contents of changed zones to their zonefile.

nsdc is removed, reload with kill -HUP $pid or use nsd-control reload. The SIGHUP makes NSD4 check zone file timestamps and reload changed zones. nsd-control reload is the same. SIGTERM stops NSD.

You probably want to install and enable some of the new NSD 4 features, such as set-up nsd-control and statistics. And you may want to use the new pattern config options.

Removed config options

difffile: ixfr.db is gone. This setting is no longer applicable, because the ixfr.db file is no longer used. Files are created in /tmp (configurable) now. The value is ignored by NSD4 if given in nsd.conf.

New config options

zonelistfile: zone.list. This file contains a plain text listing of the dynamically added zones and their pattern. It is read and written by NSD while it is running.

xfrdir: /tmp. This directory is used to store temporary zone transfer files. They are stored in a unique subdirectory that has few access permissions.

tcp-count: 100. This option already exists in NSD3, but in NSD4 you can increase it above 1024, like 2048, to have higher TCP capacity.

remote-control: this is a new section in the config file that configures the nsd-control remote control utility. It is very similar to unbound’s remote control configuration. With control-enable: yes you can enable it, it is disabled by default. It is bound to the loopback interface by default. See the manpage or sample config for the list of options, it is possible to set the port number and keyfile paths, and configure it to be accessible from the outside.

pattern: these allow you to bundle a set of zone config statements. Then for a zone you can include-pattern: “nameofpattern” to apply those config statements. patterns can also include other patterns. This is needed to allow the user to specify the config  statement pattern for a newly added zone. But you can also use it to organise the configuration.

zone: These already exist in NSD3 and work similarly. For NSD4, they create a zone that cannot be dynamically removed because it is hardcoded in the nsd.conf file. Zones that are dynamically added can also be dynamically removed, but those zones are in the  zones.list file. The zone can have the normal zone config statements, and it can also use include-pattern to apply config statements from a pattern to it.

The nsd-control Utility

You can control the NSD4 daemon with signals, SIGHUP, SIGUSR1 and SIGTERM, if you want. It reloads on SIGHUP and this includes parsing and loading changed zone files. More commands are available via the nsd-control utility. It connects over SSL with the daemon and sends the command to it, and prints the result.

To enable nsd-control you have to create the private and public keys with nsd-control-setup, run this setup script as root. Then edit nsd.conf and set remote-control: control-enable: yes in the config file. Then you should be able to use nsd-control; the nsd-control status command is a simple check if everything works.

reload [zone] : without a zone name it checks if zone files have changed, if so, loads them. If you specify the zone name (nsd-control reload example.com) it will load that zone.

repattern : this rereads the nsd.conf file without a restart. Only the zone configuration and ratelimits are updated from it. Other settings, file paths, chroot location, interfaces, and port numbers, cannot be applied and need a restart. During the restart NSD will have the permissions to bind port 53 and chroot again.

log_reopen : also done on SIGHUP, but this controls more exactly that only the logfile is reopened.

stats and stats_noreset : print statistics.

addzone name pattern : adds a new zone to the running server. If it has a zonefile this file is read in and served. If it is a slave zone, a zone transfer is attempted.

delzone name : removes zone.

write [zone] : write a zone contents from nsd.db to its zonefile in text format. writes all changed zones, but if you specify a particular zone, it writes that zone only.

notify [zone] : for master zones, send notifies to its slaves. If you specify a name, only that zone, otherwise all master zones.

transfer [zone] : for slave zones, attempt a zone transfer from the masters. If you specify a name, only that zone, otherwise all slave zones.

force_transfer [zone] : same as transfer but uses full zone transfer with AXFR and does not perform a serial number check.


With nsd-control you can get a list of statistics from NSD on demand. This makes it easier to integrate NSD into a statistics collection system. You have to compile with –enable-bind8-stats for this. In source/contrib/nsd_munin_ is an example munin plugin.

Other features

  • Performance increase.
  • Support a high zone count.
  • Faster zone transfers.
  • Add and remove zones without a restart.
  • Can reread zone configuration from config file without a restart.
  • Higher TCP service levels, more sockets.
  • Detect which zone files have changed.
  • Stores nsec3prehash on disk, and calculates incrementally after IXFR.
  • Domain tree does not have the small leak of domain nodes.

More documentation

The nsd(8) man page, the nsd.conf(5) man page, the nsd-control(8) man page.

The man pages are installed when you install the beta.

NSD 4.0 Beta: NSD4 sees the light..

by olaf

EDIT (10 jan 2013): added beta2 link.

We are proud to announce a beta version of NSD4.0.

With this beta release NSD4.0 is feature complete. Earlier we described our high-level plans with NSD4;  below we describe the features that are available in NSD4.0 and some of what we have on the TODO list for 4.1 and 4.2; while in another post the differences in configuration and migration methodology is described.

NSD 4.0 highlights

Stable: DNS Protocol Logic

The implementation of the DNS protocol logic itself has not been touched: You may expect the same query-answer behavior as with NSD3.

Internals: Radix Tree

We have modified the internal data structure to use a radix tree. We have not done (nor are we aware of) serious benchmarks, but early reports of operators that have been doing rudimentary tests indicate that the performance of NSD4 has significantly (2 digits percentage) improved over NSD3.

Response Rate Limiting (RRL)

Inspired and based on the work by Vixie and Schryver we have implemented DNS Response Rate Limiting. The NSD RRL implementation includes most of the features as described in the Vixie and Schryver paper. The implementation is done independently from scratch (following the biological diversity requirement that is at the basis of NSD) and in some details we have made different choices in order to fit to the NSD internal architecture. More details here.

Support to operate in ‘Many Zones’ environments

We have introduced a number of changes that allows better integration of environments that want to use NSD in situations where many zones are served. This is achieved through the integration of the zone compiler as an NSD process, by adding patterns that allow the specification of common configuration options among zones, such as the location of a primary server. Using the nsd-control program, zones can be added and tied to these patterns during run-time. There is no need to stop the server, recompile, and reload in order to add new zones.

In addition, we have improved the performance of the XFR transfer code by two orders of magnitude, making the operation of NSD4 in a highly dynamic environment more effective.

We believe that this makes NSD4 suitable as a secondary server for hosting and similar environments.

NSD 4.x

We continue to work on NSD4.1 and NSD4.2.

For these versions we plan to:

  • Review logging and statistics.
  • Review incremental updates.
  • Review the specifics of the response rate limiting implementation. On this issue we are looking for community feedback, mostly through the rate limits mailing list that was specifically created for discussing DNS rate limiting.



We would like to stress that this is a beta release and we are still going through final documentation and tests. That said, we welcome reports from folk that are running their code in their test or production environments. If you want to participate in beta tests, at your own risk off course, the latest version of the code is available from

sha1 ad899c3795ca5311a1fea0d38f61026338a5ff60.

There is a new beta2 version:

sha1 e093d1519bf2e3f3c458ccf41aec45dce6a84a84
sha256 966bd0a7cdc29654df6579904d6833abfcd913428d68801f49853db7867e86a5

Wed Sep 25 2013

© Stichting NLnet Labs

Science Park 400, 1098 XH Amsterdam, The Netherlands

labs@nlnetlabs.nl, subsidised by NLnet and SIDN.