lab/notes
← All notes

NSD vs Knot vs PowerDNS: why we picked one for our authoritative

April 19, 2026 · lab notes · dns · comparison

If you’re running your own authoritative DNS — for a zone you control, not for resolving — you have three serious choices in the open-source world: NSD, Knot DNS, and PowerDNS Authoritative. We tested all three for a small operator setup and ended up on Knot. Here’s the comparison.

What we needed

  • Authoritative-only (no recursive). We want zones we sign, not a public resolver.
  • Hidden primary plus secondaries. The signing happens in one place, the public servers serve from zone transfers.
  • DNSSEC out of the box. No bolted-on signing daemon.
  • Sensible operational model. We don’t want to write Lua to reload a zone.
  • Reasonable performance. We’re not running a TLD, but we want low latency under load.

NSD

NSD is the simplest of the three. It is only authoritative — there’s no recursor mode, no scripting, no database. The configuration is one file, mostly self-documenting. Performance is excellent because it does very little.

Pros:

  • Smallest attack surface
  • Fastest cold-start, lowest memory
  • Configuration is unambiguous

Cons:

  • DNSSEC signing is not built in. You sign zones offline (with ldns-signzone or dnssec-signzone), then load them. This works but means you need a separate signing pipeline.
  • No dynamic updates from API. You commit zones to disk and reload.

For an operator who already has a signing pipeline (e.g., from BIND or a key management system), NSD is hard to beat. For a small team without that pipeline, it’s more work.

Knot DNS

Knot is a Czech DNS server (CZ.NIC writes it), originally intended for TLD-scale operators. It’s authoritative-only, supports online signing with automatic key rollover, and has a control plane that’s actually reasonable to script against (knotc).

Pros:

  • DNSSEC signing built in, including automatic key generation and rollover (KSK, ZSK, both)
  • knotc for runtime control — reload zones, update keys, query status
  • Good performance, comparable to NSD for read-only loads
  • DNSSEC policy configuration is sensible (you can describe “what kind of DNSSEC” you want, and it does the rest)

Cons:

  • More moving parts than NSD
  • Documentation assumes you understand DNS — not a beginner’s tool

We picked Knot because the online signing was the deciding factor. We didn’t want to build a signing pipeline; Knot signs zones automatically and rolls keys on schedule. The cost is two more processes (knot itself plus journald sweep), which is fine on modern hardware.

PowerDNS Authoritative

PowerDNS is the swiss-army-knife option. It supports backends from BIND zonefiles to MySQL to LDAP, has an HTTP API for everything, and includes a recursor as a separate binary. It is widely used in hosting environments where DNS records need to come out of customer databases.

Pros:

  • Database backend (MySQL, PostgreSQL) means zones live in SQL, easy to integrate with provisioning systems
  • HTTP API for record updates, dnsupdate-protocol-without-the-pain
  • Lua scripting for advanced policies (geo-DNS, weighted load balancing, custom logic)
  • Active commercial development

Cons:

  • More complex to deploy. The MySQL backend means you’re operating MySQL too.
  • DNSSEC signing works but is more configuration-heavy than Knot’s
  • Performance with database backend depends on your MySQL setup

For a small operator with no need for database-backed zones, PowerDNS is more software than required. For a hosting company managing hundreds of customer zones via API, it’s the obvious choice.

What we ended up with

Knot, primary on a hidden VM that’s not in any nameserver record. Two NSD secondaries on public IPs receiving zone transfers from Knot. The split is intentional: NSD on the public side because we want minimum attack surface there, Knot on the hidden side because we need the signing.

Two processes total in our infrastructure. Configuration in version control. Zones updated by editing files and running knotc reload.

If we were starting from a single-server setup with no separate signing infrastructure, we’d run Knot on its own. If we were running a hosting platform with database-driven provisioning, we’d run PowerDNS. The “right” choice depends entirely on what you’re trying to do.

DNS server choice is one of those areas where benchmarks are misleading and architecture is everything.