NSEC Next Secure Common
Proves a name doesn't exist in a DNSSEC-signed zone by pointing to the next name in canonical order.
What it's for
An NSEC (Next Secure) record solves a problem plain DNS never had to think about: how do you cryptographically prove that a name doesn't exist? Without DNSSEC, a resolver just trusts an NXDOMAIN response at face value. With DNSSEC, every answer needs to be provably authentic — including "this doesn't exist" answers — otherwise an attacker could forge NXDOMAIN responses to hide legitimate records.
NSEC does this by listing, for a given name, what the next name in the zone's canonical (alphabetically sorted) order is, along with which record types exist at the current name. If a resolver queries a name that falls between two consecutive NSEC-linked names, it can prove that name doesn't exist — the gap between them is cryptographically signed and verifiable.
Format & syntax
alpha.example.com. 3600 IN NSEC charlie.example.com. A MX RRSIG NSEC
- Name — the current record's name
- Next Domain Name — the next name in the zone in canonical sort order
- Type Bit Map — a list of which record types exist at the current name
Reading a full zone's NSEC chain end to end reveals every single name that exists in the zone, in order — this is the notable side effect discussed below.
How it's used in practice
- Authenticated denial of existence — the core purpose: allowing a validating resolver to trust an NXDOMAIN or "no such record type" response as much as it trusts a positive answer, closing a real DNSSEC gap.
- Zone walking (a known side effect) — because NSEC records form a complete chain covering every name in the zone, anyone can "walk" the chain by repeatedly querying and following the "next name" pointers, effectively enumerating the entire zone's contents — every subdomain, even ones never advertised anywhere. For zones where the list of subdomains itself is sensitive, this is considered undesirable.
- NSEC3 as the modern default — because of the zone-walking concern, most DNSSEC-signed zones today use NSEC3 (which hashes names before including them in the chain) instead of plain NSEC, specifically to prevent trivial enumeration.
Common mistakes & gotchas
- Not realizing NSEC exposes your entire zone — if privacy of subdomain names matters to you (internal service names, unreleased product subdomains, etc.), using plain NSEC instead of NSEC3 on a DNSSEC-signed zone means anyone can enumerate every name in your zone through a straightforward walking technique.
- Confusing NSEC with a normal "record not found" mechanism — NSEC only matters in the context of DNSSEC validation; non-validating resolvers and most everyday tooling don't interact with it directly.
- Manually managing NSEC records — like DNSKEY and RRSIG, NSEC records are generated automatically by DNSSEC signing software/services as part of the signing process — you don't hand-author them.
Comparison & FAQ
| Type | Purpose | Key difference from NSEC |
|---|---|---|
| NSEC3 | Same purpose (denial of existence), but with hashed names | Prevents the zone-enumeration issue that plain NSEC has |
| RRSIG | Signs a recordset, including NSEC records themselves | RRSIG is the signature mechanism; NSEC is the specific data structure being signed here |
What's the practical difference between NSEC and NSEC3?
They serve the same purpose (proving a name doesn't exist), but NSEC lists actual names in plaintext, allowing full zone enumeration by walking the chain, while NSEC3 hashes the names first, making enumeration significantly harder (though not theoretically impossible against short/guessable names).
Should I use NSEC or NSEC3 for my zone?
NSEC3 is the more common modern default specifically because it avoids trivial zone-walking. Most DNS providers with DNSSEC support default to NSEC3 automatically.
Do I need to configure NSEC records manually?
No — they're generated automatically as part of the DNSSEC zone-signing process, alongside RRSIG and DNSKEY records.
Does NSEC affect non-DNSSEC-validating resolvers?
Not meaningfully — resolvers that don't validate DNSSEC generally ignore NSEC records and just process the normal answer or NXDOMAIN response as they always would.