NSD (version 3) is a blindingly fast authoritative DNS server created by NLnetLabs, the fine people who also created the Unbound recursive server. Quoting myself:

NSD uses master zone files (the same files as those used by BIND). You compile these into a binary database using NSD’s zone compiler. Pre-compiling zone data lets NSD start up very quickly. NSD evolved out of a server designed to power the K.ROOT-SERVERS.NET installation. NSD is authoritative only, i.e. it will not answer queries for which it isn’t responsible. It cannot act as a caching or recursive server. NSD can be set up as a master name server and as a slave name server.

A new version called NSD4 is on the horizon, and I want to look at some of its new features.

As described above, one of NSD3’s major features is that zone data is “compiled” into a database from which NSD3 serves replies. While it is precisely that what makes NSD3 so fast, it is simultaneously one of its major drawbacks: adding new zones to NSD3 is a bit of a convoluted process: nsd.conf has to be updated, the internal database has to be “recompiled”, and NSD3 has to be reloaded.

While this is fine for environments with a relatively static number of zones, it has always been a drawback for organizations (e.g. hosters) with many zones that come and go. NSD4 addresses this problem, and that is what I’m going to look at here. (BTW, if you currently use NSD3, migration to NSD4 ought to be quite easy.)

Configuration of NSD4 is mostly unchanged, but there are some new bits in nsd.conf:

server:
        database: "/usr/local/nsd4/etc/nsd/nsd.db"
        zonesdir: "/usr/local/nsd4/etc/nsd/zones"
        zonelistfile: "/usr/local/nsd4/etc/nsd/zones.list"
	...

remote-control:
        control-enable: yes
        control-interface: "127.0.0.1"
        control-port: 8952
        server-key-file: "/usr/local/nsd4/etc/nsd/nsd_server.key"
        server-cert-file: "/usr/local/nsd4/etc/nsd/nsd_server.pem"
        control-key-file: "/usr/local/nsd4/etc/nsd/nsd_control.key"
        control-cert-file: "/usr/local/nsd4/etc/nsd/nsd_control.pem"

pattern:
        name: "sl"
        zonefile: "sl-hosts/%s.zone"
        request-xfr: 10.0.12.1 NOKEY
        request-xfr: 10.1.43.5 NOKEY
        provide-xfr: 0.0.0.0/0 NOKEY

pattern:
        name: "pdns"
        zonefile: "slaves/%1/%s.zone"
        request-xfr: 192.168.1.3 NOKEY
        request-xfr: 192.168.1.4 NOKEY

The server stanza describes server settings, and most of those are unchanged as are the settings for specifying master zones.

The old nsdc utility from NSD3 has been replaced with a remote-capable tool aptly named nsd-control which operates similarly to Unbound’s unbound-control: it also requires a pair of SSL certificates to talk to the server; you either provide your own, or you create them up with the nsd-control-setup shell script.

All new, and this is where I find it gets exciting, are the zonelistfile directive (in the server stanza) and the pattern directives, which allow us to introduce new slave zones into NSD4 without touching its configuration files. (This is similar in concept to adding zones to a BIND name server with addzone if less messy because I can “predefine” master servers, TSIG keys etc., which I cannot do for BIND.)

Think of patterns as groups. Here I have a pattern (or a group) called “sl”, and another called “pdns”. Each of these provides a directory (which can be different) and a number of master servers responsible for the “pattern”.

If I now launch the following command, NSD4 will add the new slave zone to the zonelistfile and will attempt a zone transfer from the slave servers specified in the pattern I defined as “pdns”:

$ nsd-control addzone big.aa   pdns
ok

The zone is transferred into NSD4’s internal database, and it is written out on demand with nsd-control write. Here’s a snippet from the server log:

[1359738155] nsd[6825]: info: new control connection from 127.0.0.1
[1359738155] nsd[6825]: info: remote control connection authenticated
[1359738155] nsd[6825]: info: control cmd:  addzone big.aa pdns
[1359738155] nsd[6825]: info: remote control operation completed
[1359738155] nsd[6825]: info: Handle incoming notify for zone big.aa
[1359738155] nsd[6825]: info: xfrd: zone big.aa written received XFR from 127.0.0.1 with serial 35 to disk
[1359738155] nsd[6825]: info: xfrd: zone big.aa committed "received update to serial 35 at 2013-02-01T17:02:35 from 127.0.0.1"
[1359738155] nsd[6830]: info: zonefile slaves/b/big.aa.zone does not exist
[1359738155] nsd[6833]: info: zone big.aa. received update to serial 35 at 2013-02-01T17:02:35 from 127.0.0.1 of 1361 bytes in 0.000412 seconds
[1359738155] nsd[6825]: info: Zone big.aa serial 0 is updated to 35.
...
...
[1359738248] nsd[6825]: info: control cmd:  write
[1359738248] nsd[6825]: info: remote control operation completed
[1359738248] nsd[6836]: info: writing zone big.aa to file slaves/b/big.aa.zone~

I can specify tokens to instruct NSD4 where I want zone files written to. The following magic characters are allowed in zonefile, and required directories are created automatically. For a zone called “hosts.example.net”:

• %s specifies the zone name ("hosts.example.net")
• %1 is the first character of zone name ("h"), %2 the second ("o"), and %3 the third ("s")
• %z names the top-level domain label of zone ("net"), %y the next ("example"), and %x the third ("hosts")
• if a label or character does not exist you get a dot (".") (Careful: you probably don’t want that as a path component!)

Zones can also be removed from a running NSD4 instance: the delzone command does that. As far as adding new master zones, the procedure is similar to how it used to be: master zones are added by creating the zone file, adding them to nsd.conf and using reconfig to have the daemon reconfigure itself.

Another feature you might be interested in (because it’s being discussed a lot) is rate-limiting: NSD4 implements DNS Response Rate Limiting as proposed by Paul Vixie and Vernon Schryver. I’ll save that for a later posting.

NSD4 is still in beta, but you can download and experiment with it. If you need help, the mailing-list is the place to go to.