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.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.