What is NSEC?
Next Secure record
An NSEC (Next Secure) record is a DNSSEC record that proves a name or record type doesn't exist, by naming the next name that does exist in the zone.
A signature can only cover data that exists, so DNSSEC needs a signed way to say "nothing here". It sorts every name in the zone into a fixed canonical order and links each name to the next with an NSEC record, which lists the next name and the record types present at the current one. For example, mail.example.net. IN NSEC ns1.example.net. A RRSIG NSEC says there are no names between mail and ns1, and that mail has only A records. A query for missing.example.net falls in that gap, so the server returns that NSEC with its RRSIG as proof of NXDOMAIN. A query for an MX record at mail gets the same NSEC as proof that the name exists but has no MX. NSEC is defined in RFC 4034.
The side effect is that anyone can follow the chain from name to name and list the whole zone, known as zone walking. NSEC3 (RFC 5155) was designed to make this harder. It works the same way, but over hashed names, so the chain links hashes rather than readable names. It doesn't make the zone secret, because the hashes of common names can be guessed offline. Current advice (RFC 9276) is to use NSEC3 with no extra hash iterations and no salt, as heavier settings mostly cost CPU. NSEC needs no maintenance by hand: PowerDNS builds the ordering when you run pdnsutil rectify-zone, and pdnsutil show-zone says whether a zone uses NSEC or NSEC3. The PowerDNS on Debian lesson signs zones with NSEC.
Lessons that use NSEC
- PowerDNS on Debian: authoritative, secondary, DNSSEC and recursorTeaches this term · Intermediate · 60 min
Build a complete DNS service on Debian with PowerDNS: authoritative primary and secondary servers with NOTIFY and AXFR, zones by pdnsutil and the HTTP API, DNSSEC signed all the way from a lab root, and a validating recursor for the office.