NSD: the NLnet Labs authoritative name server for operators who want boring DNS

What NSD is, and the four words that define it

The NLnet Labs Name Server Daemon is an authoritative DNS name server, and the README describes it as having been developed for operations in environments where speed, reliability, stability and security are of high importance.

That list of four is the design brief. It is worth reading it as a rejection of features. NSD is not a resolver: it holds zones and answers authoritatively from them, and it does not perform recursive lookups on behalf of clients. It is not a management platform with a web interface, a database of customer accounts or a billing system. It is a name server that is expected to keep answering.

The consequence is visible in the codebase, which is written in C and organised almost entirely around protocol handling. The top level is a long flat list of C sources and headers named for what they do: answer.c for building responses, axfr.c for zone transfers, bitset.c for bitmap data structures, dname.c for domain name handling, dns.c for the core protocol, edns.c for EDNS support, ixfr.c for incremental zone transfers, namedb.c for the zone database, and netio.c for network I/O. There are also dbaccess.c and dbcreate.c for the database files that hold the zone data on disk, difffile.c for diffing zone files, and metrics.c for exposing measurements.

The build system is GNU Autotools, with configure.ac, acx_nlnetlabs.m4 for the project specific macros, Makefile.in, a configlexer.lex and a configparser.y, which is a hand written lexer and parser for the configuration file rather than a configuration library. nsd-checkconf.c and nsd-checkzone.c are separate programs for validating a configuration and validating a zone, each with its own man page template.

The project is BSD-3-Clause licensed, the homepage is nlnetlabs.nl/nsd, and the last push was on 2026-10-14.

The release structure, and why a 4.15.3 security release matters

The recent release list is a good illustration of how this project is maintained.

There are three entries. NSD 4.15.3 is a security release, dated 2026-10-14. NSD 4.15.4rc1 is a pre-release, dated the same day but published slightly later. And NSD 4.15.2 is a normal release, dated 2026-09-02.

The interesting detail is that the 4.15.4 pre-release came out on the same day as the 4.15.3 security release, and after it. That is the normal pattern for a project that ships a security fix quickly and then prepares the next point release on the same branch, but the ordering here is worth noting for a deployment plan: the security fix is available now, and the next point release is not yet final.

The release naming is also informative. The tags use a separated form, NSD_4_15_3_REL, and the release titles describe what they are, with NSD 4.15.4rc1 pre-release and NSD 4.15.2 released. For an operator, the practical reading is that there is a released version with a security fix in it, and a candidate for the one after it. Whether to take the release candidate depends on whether you want the fixes early enough to be useful and the churn of an rc.

The version numbering is a plain four component scheme where 4 is the major line, 15 the minor and 3 the patch, and it has been climbing for a long time, which is the sign of a project with a very stable branch structure and a long supported 4.x series.

The README also states where feedback goes, with an invitation to create a GitHub issue or post on the community forum, and the documentation is hosted separately at nsd.docs.nlnetlabs.nl.

Building it: autotools, the simdzone submodule and two shell commands

The build instructions are short and they exist because building from git differs from building from a release tarball.

The prerequisites are a C toolchain, meaning the set of tools to compile C such as a compiler, linker and assembler, plus OpenSSL with its include files, libevent with its include files, flex and bison. The include files are usually in the dev version of the library on most distributions.

The toolchain is worth noting for what it says about the project. flex and bison are needed because the configuration parser is hand written, and libevent is the event loop underneath the network handling. OpenSSL is there for the DNSSEC signing and verification.

When building from Git, the configure script and the simdzone sources are missing, so the first two commands are:

$ git submodule update --init
$ autoreconf -fi

The README is explicit that the configure script and sources are included in release tarballs and do not need to be generated or downloaded, so the submodule step applies only to a git checkout. simdzone is a separate NLnet Labs project, and it is the one dependency here that is not a well known library, so it is worth knowing that the zone parsing code comes from elsewhere rather than from this tree.

The autoreconf note explains a common failure. autoreconf should install the required auxiliary files, such as config.sub and config.guess, and older versions of autoreconf may not do so, in which case you should try running libtoolize -fi -c first.

And then the ordinary build:

$ ./configure && make && make install

This is a plain autotools build with no package manager involved, which is normal for a nameserver that gets packaged by distributions rather than installed from a language registry.

Configuration by man page, and the tools that come with it

NSD does not use a configuration format that a documentation site explains well. The README points you at the man pages, which are installed with the software so you can read them with man nsd.conf, and the same options are documented on the project's documentation page.

The man page being the primary reference is a deliberate choice for a server like this, because the configuration file is the security boundary. A wrong option in a nameserver can expose a zone, allow a transfer that should not happen, or write a control socket in a world readable place. Putting the authoritative description in a document that ships with the installed binary, rather than on a website that can change underneath you, is a defensible decision for that kind of software.

An example configuration is available as nsd.conf.sample.in in the repository, with the .in suffix marking it as a template that the build system turns into nsd.conf.

The repository also contains a set of command line tools, and their presence tells you what operations are supported. There is nsd-checkconf, which validates a configuration file, and nsd-checkzone, which validates a zone, both with their own man page templates in .8.in form. There is nsd-control-setup.sh.in, which is the setup script for the control interface. There is axfrcreate.c and ixfrcreate.c, which create the zone transfer files that a secondary server consumes, and difffile.c which handles diffing those files.

The transfer and zone handling code is a large part of the tree, which is consistent with the project's role. An authoritative server spends most of its life receiving zone updates, signing them, answering queries and serving transfers to secondaries, and the code for each of those is present.

There is also a doc/ directory and a .readthedocs.yaml, so the reference documentation is built from files in the tree rather than hosted by hand.

The subsystems the source tree reveals

Beyond the obvious protocol files, the top level directories and modules show the shape of the project in more detail.

There is a dnstap/ directory, which is the logging interface for sending DNS query and response data to a collector, a protocol originally designed for passive DNS analysis. There is an ipc.c and ipc.h, the inter-process communication used to talk to the control interface, and a compat/ directory for portability shims. There is a contrib/ directory for contributed extras.

The metrics.c file is worth pausing on. Modern operators expect to be able to scrape a name server, and having metrics in the tree means a Prometheus style endpoint is part of the product rather than something bolted on by a third party. For a service whose whole job is to be available, being able to alert on its internal state without parsing logs is a real operational property.

The zone data is kept in database files, given away by dbaccess.c and dbcreate.c, which is the classic approach for an authoritative server: parse the zone once, write it into a compact on disk structure, and serve queries from that rather than re-parsing text on every lookup. The files for that are separate from the protocol code, which is a clean separation.

Two other files show attention to detail that is easy to miss. iterated_hash.c and lookup3.c are hash implementations, present because DNS uses both specific and non cryptographic hashing for specific purposes, and a name server that has to look up names fast will not use a general purpose hash for everything. And mini_event.c is the event handling, distinct from libevent, which is the network event library.

The overall impression is of a codebase organised by protocol function rather than by feature, which is what you would expect from a server that has been developed for a long time by people who work on DNS rather than on applications.

Editorial conclusion

Adopt NSD when you need an authoritative name server that does one job well and that you will operate for years, especially alongside a separate recursive resolver, since NSD is authoritative only and will not resolve anything for you. Do not adopt it as a general purpose resolver or as a substitute for a full DNS suite, because the recursive path is not its purpose. Before you deploy, read the man pages for the configuration options rather than relying on a sample file, and set up the zone transfer and DNSSEC parts deliberately, since the security boundary in this server is the configuration and the signing keys.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. NLnetLabs/nsd on GitHub
3. Project website
4. README
5. Releases