NSEC (Next Secure) records provide authenticated denial of existence in DNSSEC. A signed zone cannot simply say "no such name", because that answer would be unsigned and forgeable. Instead it returns an NSEC record that lists the next existing name in sorted order and the record types present at the current one, along with its signature.
Why it matters
A resolver can check that the queried name falls in the gap between two real names, so the answer "does not exist" is verifiable. A side effect is zone walking: by following the chain of NSEC records, anyone can enumerate every name in the zone. NSEC3 (RFC 5155) mitigates this by hashing the names, which makes enumeration harder but not impossible, since weak names can still be guessed offline. NSEC3 adds salt and iteration parameters, and current guidance recommends keeping iterations at zero.
Example
alpha.example.com. 300 IN NSEC gamma.example.com. A RRSIG NSECA query for beta.example.com is proven nonexistent because it sorts between alpha and gamma.
Common mistakes
- Thinking NSEC3 makes names secret.
- Using a high iteration count, which burdens resolvers and is discouraged.
- Forgetting to re-sign the chain after zone changes.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.