Skip to main content
DNSSEC adds signatures to DNS answers. Validating resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9, modern ISPs) check them against a DS record at your domain registrar, so nobody in between can forge an answer for your zone. DNZ signs the answers of local zones, one zone at a time. To have DNZ check the signatures of other domains it resolves for your clients, see DNSSEC validation.
DNSSEC is only useful when DNZ is the zone’s public nameserver. For zones on Cloudflare, turn on DNSSEC at Cloudflare. Internal zones (such as corp.local) have no public DS; internal resolvers can use their DNSKEY as a trust anchor if needed.

​
Turn it on

1

Turn on DNSSEC for the zone

Open the zone under DNS → Zones and turn on DNSSEC (needs the Manage zones permission). To sign with something other than the defaults, open Signing settings first (see below). Or from the terminal:
DNZ creates the zone’s key (one ECDSA P-256, algorithm 13 key by default) and starts signing its answers right away.
2

Add the DS record at your registrar

Copy the DS record shown and add it at your domain registrar (or in the parent zone). Most registrars ask for the Key tag, Algorithm, Digest type (2) and Digest. Some ask for the DNSKEY (public key) instead; the card shows both.
3

Check the chain of trust

Once the DS is published, run the checks below.
Until the DS is in place, the zone works as before, just unvalidated (“insecure”).
A signed zone answers every name in it itself, so Forward missing names is turned off when you turn DNSSEC on, and can’t be turned back on while the zone is signed.

​
Signing settings

Ed25519 gives the smallest answers; RSA is there for parents and validators that need it. Changing the algorithm or the key split of a signed zone starts a rollover; it can’t be changed again until that rollover has finished.
  • Compact denial (RFC 9824, “black lies”): a missing name or type gets a NOERROR answer with an NSEC that covers only the queried name (type NXNAME for names that don’t exist). Nothing is computed ahead and the zone’s contents can’t be walked. Some older validators and monitoring tools expect NXDOMAIN for missing names.
  • NSEC3 (RFC 5155, opt-out off): missing names get a real NXDOMAIN with the closest encloser proof, missing types an NSEC3 matching the name, and wildcard answers are signed as the wildcard with the next closer name proven missing. The hashed chain is computed once per version of the zone, and the apex answers NSEC3PARAM.
RFC 9276 asks for 0 extra NSEC3 iterations and no salt: neither makes hashed names much harder to guess, both cost resolvers work, and validators may treat high iteration counts as insecure.

​
Key rollover

DNZ rolls keys by itself; each step waits long enough for caches to forget what they had. The zone page shows the rollover in progress, each key’s state and when the next step is due. Start one by hand with Roll KSK / Roll ZSK / Roll CSK, or:
  • ZSK (pre-publish, RFC 6781): the new ZSK is published first, starts signing once the DNSKEY RRset’s TTL (1 hour) plus a margin has passed, and the old one stays published until the zone’s longest TTL plus a margin has passed. Nothing changes at the registrar.
  • KSK or combined key (double signature): the new key signs next to the old one at once. Once caches have the new DNSKEY RRset, CDS and CDNSKEY (RFC 7344) switch to the new key and the zone page shows the new DS. The rollover then waits for the parent zone’s DS to point at the new key.
  • Algorithm (RFC 6781 section 4.1.4): the new keys sign everything before they are published, are published once the zone’s longest TTL has passed, take over the DS like a KSK, and the old keys leave the DNSKEY RRset before they stop signing.
  • One key ↔ KSK + ZSK with the same algorithm needs no new DS.
1

Update the DS

When the zone page says it’s waiting for the parent, put the new DS at your registrar. Registrars and registries that read CDS (RFC 8078) do it by themselves.
2

DNZ notices

DNZ looks up the zone’s DS through its upstreams every 15 minutes while it waits. Where that can’t work (an internal zone), confirm with The registrar has the new DS, or:
3

The old key goes

Two days later (the parent’s DS TTL plus a margin), the old key is removed.

​
How it works

  • Online signing: every answer is signed as it is sent, for clients that set the DO bit, by each key that signs that RRset. No zone needs re-signing and no signature expires unnoticed. Record changes are signed immediately.
  • DNSKEY, CDS and CDNSKEY (and NSEC3PARAM with NSEC3) are answered automatically at the zone apex.
  • Views, wildcards, CNAMEs, DNAMEs and Auto PTR are signed too; a CNAME chain that ends at a missing name carries the proof for that name.
  • Disabled records and disabled zones are not signed (they aren’t answered either).
  • Keys are kept when DNSSEC is turned off, so turning it on again doesn’t change the DS.
  • DNZ secondaries of a signed zone receive the same keys from the primary, with their rollover states, so one DS covers every DNZ nameserver. Only the primary rolls keys. See Replication.

​
Check it

Before the DS is at the parent, validate against DNZ directly with the DS as a trust anchor (BIND 9.18’s delv):
Replace 192.0.2.10 with your DNZ server’s address. DNSViz and the Verisign DNSSEC Debugger work too.

​
Turn it off

1

Remove the DS at the registrar

Delete the DS record at your registrar first.
2

Wait for its TTL

Wait for the DS record’s TTL to run out, usually a day.
3

Turn DNSSEC off in DNZ

Only then turn DNSSEC off on the zone page.
While the DS is still published but answers are no longer signed, validating resolvers reject the zone (SERVFAIL).

​
Secondaries that aren’t DNZ

Zones are transferred without signatures, because DNZ signs answers online. A BIND, Knot or PowerDNS secondary therefore serves them unsigned. For signed zones, use DNZ secondaries (they share the key), or sign on the secondary with its own key and add its DS too. See Replication.