Why a negative DNS answer needs proof
When you ask for a DNS name that does not exist, a DNS server may return NXDOMAIN. If the name exists but has no record of the requested type, it can instead return a “no data” answer, often called NODATA. Those answers matter: an attacker who could forge one might make a working website or mail service appear unavailable.
DNSSEC gives a validating resolver a way to check negative answers from a signed zone. The zone publishes records that describe gaps in its namespace, along with DNSSEC signatures. The resolver validates those signatures through the usual chain of trust and checks whether the records actually cover the question it asked. A signature alone is not enough if the signed record describes a different name or gap. An unsigned zone cannot provide this DNSSEC proof.
NSEC: showing the gap between names
An NSEC record names the next existing name in a zone’s ordered list of names. Imagine a simplified signed zone with alpha.example.test followed by delta.example.test. An NSEC record at alpha.example.test pointing to delta.example.test can show that a name falling between them in DNSSEC’s ordering is not present. The signed record makes that statement verifiable; it is not merely the server’s unsupported claim that the name is missing. The list also wraps around from the last name to the first.
NSEC has another job: its type bitmap lists the DNS record types present at its owner name. If a name exists but the requested type is absent from that signed list, the resolver can validate a NODATA answer. These checks are about the zone’s published DNS data, not whether a device or website is currently running.
Wildcards make nonexistence less simple
A missing exact name does not always mean the answer must be NXDOMAIN. A zone might contain a wildcard such as *.example.test that can supply an answer for names without an exact match. For that reason, DNSSEC validation of a negative answer may need evidence about both the requested name and the relevant wildcard. The precise records needed depend on the name being queried and the zone’s structure.
For example, proving that a specific name is absent would not by itself justify NXDOMAIN if a matching wildcard could answer the query. NSEC records can provide the additional evidence needed to rule out that possibility. They also help distinguish an absent name from an existing name that simply lacks an A, MX, or other requested record type. This is why a DNSSEC negative response can contain more records than an ordinary-looking “not found” message suggests.
NSEC3: proving gaps using hashed names
NSEC makes names in a signed zone relatively easy to discover by following its ordered chain. NSEC3 uses a similar gap-proof idea but orders hashed versions of names instead. Its records identify a hashed owner name and the next hash in the chain. A validating resolver applies the zone’s stated hash settings to the relevant name, then checks signed NSEC3 records to see whether that hash matches an existing entry or falls in a covered interval. NSEC3 also has a type bitmap for proving that a record type is absent at an existing name.
Hashing does not make names secret. Someone may still be able to guess likely names and test them against the published hashes. NSEC3 can make straightforward zone walking less revealing, but it should not be treated as a privacy boundary. NSEC3 also supports an opt-out feature, typically used around unsigned delegations. An opt-out interval makes a narrower statement than an ordinary proof that every covered name is absent, so its meaning needs careful handling by validating resolvers.
What a validated negative answer tells you
A successful NSEC or NSEC3 check tells a resolver that the negative answer is consistent with the signed DNS data it can validate. It does not prove that a website is healthy, that an email address is usable, or that the zone owner intended to omit the name. A configuration mistake can be signed just as readily as a correct configuration.
If you troubleshoot a missing name, first separate the two questions: does the name exist, and does it have the record type you requested? Then check whether the zone is signed and whether your resolver reports a DNSSEC validation failure rather than an ordinary negative answer. NSEC and NSEC3 help establish what the signed zone says is absent; they do not replace checking the zone’s intended configuration.
