NSEC record
Authenticates DNSSEC denial of existence by naming the next owner name and listing the types present at the current name.
Written and maintained by Ben Ennis
Last reviewed July 27, 2026 · How we verify this
Zone-file example
www.example.com. 3600 IN NSEC api.example.com. A AAAA HTTPS RRSIGTypical uses
- Proving that a queried name does not exist in a signed zone
- Proving that an existing name lacks a requested record type
- Diagnosing DNSSEC validation failures around empty non-terminals
- Inspecting the canonical name intervals used for authenticated denial
When it breaks, check
- The NSEC RRset must be accompanied by a valid RRSIG for a validating resolver to trust it
- The next owner name is canonical DNS order, not necessarily the next label someone expects alphabetically
- An NSEC proof can show a name exists while the requested type is absent
- Check wildcard and delegation proofs separately; one NSEC record rarely explains the whole response
What the NSEC record does
NSEC forms a signed interval across the names in a DNSSEC zone. If a query falls between the owner name and the next name, the interval proves that no such owner exists. If the owner exists but its type bitmap omits the requested type, the same structure can prove a type-specific denial. Empty non-terminals and wildcard answers require additional proof records, which is why a DNS response can contain several NSEC and RRSIG records.
The type bitmap is part of the proof, not a list of every record the resolver should query. NSEC exposes the names in its interval, which may be undesirable for some zones; NSEC3 uses hashed owner names instead. To inspect a live response, use the DNS lookup tool with DNSSEC data enabled.
Zone-file and wire format
NSEC RDATA is next-domain-name type-bitmap. The next domain name is the following owner in canonical DNSSEC order, wrapping from the final name back to the first. The bitmap lists RR types present at the owner, such as A, AAAA, RRSIG, and NSEC. An NSEC record is signed by an RRSIG record and is normally published with the zone’s DNSSEC material.
; illustrative interval and type bitmap
www.example.com. 3600 IN NSEC api.example.com. A AAAA HTTPS RRSIGCommon uses
NSEC is the straightforward denial-of-existence mechanism for signed zones and is often easiest to troubleshoot because the names are visible. It also supports authenticated responses for negative caching. It does not encrypt DNS data or hide the zone’s names. Use DS and DNSKEY to inspect the chain of trust, and use SOA when a resolver’s negative TTL appears surprising.
Troubleshooting
Start with a query that requests DNSSEC records, then identify the NSEC and RRSIG records that cover the queried name or missing type. Validate the signature against the zone’s DNSKEY and confirm that the response’s authority section has not been stripped by a forwarding layer. Compare an authoritative answer with the recursive answer to separate zone data from cache behavior.
For a false NXDOMAIN, check wildcard expansion, delegation cuts, and canonical ordering before editing records. For a SERVFAIL from validating resolvers, check RRSIG expiration, the DNSKEY-to-DS chain, and whether a recently changed NSEC RRset has reached every authoritative server.
dig example.com missing-name A +dnssec
dig example.com NSEC +dnssec +noall +answer +authority
# Ask an authoritative server without recursion.
dig @ns1.example.net missing-name A +norecurse +dnssecThe defining RFC
NSEC is defined by RFC 4034, section 4 and its DNSSEC denial semantics are described with the validation rules in RFC 4035. The type bitmap encoding is specified in RFC 4034. See the IANA DNS Parameters registry for the assigned type.
Reference and tooling
Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.