NSD (name server daemon) is an open-source authoritative-only DNS server developed by NLnet Labs that answers queries for configured zones without performing recursion or caching, making it lightweight and secure for organizations that pair it with a separate recursive resolver. By design, NSD eliminates the open recursion vulnerability common in combined authoritative-recursive servers, and its narrow focus simplifies code maintenance, capacity planning, and attack surface. Organizations must manage zone consistency through proper DNS NOTIFY and zone transfer configuration, monitor for stale secondaries and transfer failures, and ensure firewall rules permit both UDP and TCP on port 53 to support full DNSSEC validation and large responses.
How NSD works
NSD loads zone data it is configured to serve and answers queries for those zones. It does not resolve names on behalf of clients, so it never queries other servers to find answers for zones it does not hold.
- Load zone data: NSD reads zone files, or receives zones from a primary server, and compiles them into a database it uses to answer queries.
- Receive a query: A resolver sends a DNS query over UDP or TCP to port 53. NSD checks whether the queried name falls inside a zone it serves.
- Answer authoritatively: If the name is in a hosted zone, NSD returns the matching records, a referral to a delegated child zone, or a negative answer. If it hosts no matching zone, it returns a refusal rather than looking the name up elsewhere.
- Synchronize secondaries: When NSD acts as a primary or secondary, it uses DNS NOTIFY and zone transfers to keep copies of a zone consistent across servers.
NSD can serve DNSSEC-signed zones, but zone signing is handled by separate tooling. Because it is authoritative only, organizations pair it with a separate recursive resolver for client lookups.
Common NSD issues
A secondary NSD instance keeps serving an old zone version when NOTIFY messages are blocked or the primary's serial was not incremented. Symptoms are different answers from different name servers for the same name.
Zone transfers fail when the primary's allow-transfer settings, firewall rules or TSIG key and algorithm do not match the secondary's configuration. Logs on the secondary show repeated transfer failures and the zone never loads.
A typo in a zone file can leave a zone unloaded or keep the previous version in service after a reload. Running the bundled zone and configuration checking tools before reloading catches most of these.
Firewalls that permit only UDP on port 53 break zone transfers and large or truncated responses, including many DNSSEC answers. Clients then see intermittent failures only for big responses.
Clients pointed at an NSD host as their resolver get refused or empty answers for names outside its zones. NSD does not recurse, so a separate resolver must serve client lookups.