DNS glossary

What is NSD (name server daemon)?

Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button
Key takeawaysKey takeaways are generated with AI assistance. Because automated summaries can occasionally contain errors or miss important context, always refer to the full blog post for complete information.

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.

  • NSD loads zone data from files or primary servers and uses DNS NOTIFY and zone transfers to maintain consistency across secondary copies without supporting client recursion.
  • NSD can serve DNSSEC-signed zones and authenticate zone transfers using TSIG shared keys, with access control entries limiting which peers may request or send zones.
  • Common operational issues include stale secondary zones when NOTIFY is blocked, transfer failures due to mismatched TSIG keys or allow-transfer settings, and TCP blocking at firewalls that prevents large DNSSEC responses.

NSD at a glance

AttributeValue
Full namename server daemon
Categoryauthoritative DNS server software
Protocol and portDNS over UDP and TCP, port 53
OSI layerApplication layer (layer 7)
Primary useServing DNS zones as an authoritative name server without recursion
Related termsAuthoritative name server, Recursive resolver, DNS zone, Zone transfer, DNSSEC, Unbound

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Why NSD matters in enterprise networks

Authoritative servers hold the published answers for a domain, so their availability determines whether the domain can be resolved at all. NSD is built only for this role. Leaving out recursion and caching reduces the code and the features that can be attacked, and it simplifies capacity planning because load depends on query volume for hosted zones rather than on client lookup behavior.

Running authoritative and recursive functions on separate software is a long-standing operational practice. A resolver that also answers authoritatively can be exposed to cache poisoning and abused for reflection and amplification attacks if recursion is open to the internet. An authoritative-only server such as NSD avoids the open recursion problem by design, though it still needs rate limiting and sound network controls.

Poor management shows up as stale or inconsistent zones. If zone transfers fail or a secondary stops receiving NOTIFY messages, servers can return different answers for the same name. Under DNSSEC, expired signatures cause validating resolvers to treat answers as bogus, which makes the domain appear to be down. Many operators also run more than one software implementation across their name server set so that a single software flaw does not take the whole zone offline.

NSD vs BIND

NSD only answers authoritatively, while BIND can run as an authoritative server, a recursive resolver, or both in one process. What is BIND?

AttributeNSDBIND
RoleAuthoritative onlyAuthoritative and recursive
Recursion and cachingNot supportedSupported
DeveloperNLnet LabsInternet Systems Consortium
ScopeNarrow, focused on serving zonesBroad feature set covering many DNS functions

NSD vs Recursive DNS server

NSD answers only for zones it hosts, while a recursive DNS server resolves names for clients by querying other servers and caching the results. What is Recursive DNS server?

AttributeNSDRecursive DNS server
Primary functionPublishes answers for hosted zonesLooks up answers on behalf of clients
Queries other serversNoYes, starting from the root or a forwarder
Typical clientsResolversStub resolvers and end devices

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.

See how unified DDI simplifies network operations

Manage DNS, DHCP and IP addresses from one platform with automation, visibility and control built in.

NSD FAQ

Related terms

Article

Authoritative DNS server / Authoritative name server

An authoritative DNS server provides original and definitive answers to DNS queries.

Learn more
Article

BIND

BIND is widely-used software that publishes DNS information on the internet and resolves DNS queries for users.

Learn more
Article

Recursive DNS server

A recursive DNS server is the first server contacted by a requesting host; it retrieves the proper IP address of the intended domain name and returns it to the requester.

Learn more
Article

DNS zone

A DNS zone is a contiguous portion of the domain name space for which administrative responsibility and authority have been delegated to a single manager.

Learn more
Article

Transaction Signature (TSIG)

TSIG (transaction signature) is a protocol that enables DNS to authenticate updates to a DNS database, most commonly for dynamic DNS or secondary DNS servers.

Learn more
Article

DNSSEC (Domain Name Service Security Extension)

DNSSEC (Domain Name Service Security Extension) is a mechanism that uses cryptography to authenticate DNS data and verify the integrity of DNS queries and responses.

Learn more
Article

NS record

An NS record is a DNS record that provides a list of the authoritative name servers responsible for a domain.

Learn more
Article

SOA record

An SOA record is a DNS record type that provides important details about a DNS zone and is required for every DNS zone.

Learn more