Skip to content

Archive

NSEC3

4 articles
Cybersecurity 24 Sep 2026 6 min read

NSEC3 Hashes DNSSEC Denial Records Without Hiding Guessable Names

A DNSSEC signature can authenticate data that exists, but a resolver also needs cryptographic evidence when a requested name or record type is absent. A plain unsigned NXDOMAIN response cannot provide that property: an attacker able to alter DNS traffic could fabricate the same response. NSEC3 supplies signed denial records while replacing clear-text owner names in the denial chain with hashes. RFC 5155 defines NSEC3 as an alternative to NSEC for authenticated denial of existence. Its main privacy-related distinction is narrow but useful: walking an NSEC chain directly reveals neighboring owner names, whereas NSEC3 exposes hashes that require additional work to map back to candidate names.

Cybersecurity 23 Sep 2026 6 min read

NSEC3 Opt-Out Trades Denial Proof for Delegation Scale

DNSSEC needs a cryptographic answer not only when data exists, but also when a requested name or record does not exist. NSEC3 supplies that negative proof through a chain of hashed owner names. For zones dominated by delegations to unsigned children, representing every insecure delegation in that chain can create substantial maintenance work. NSEC3 Opt-Out changes that trade-off. An Opt-Out span may cover insecure delegations without giving each one a matching NSEC3 record. The result can reduce NSEC3-chain updates in large delegation-heavy zones, but the omitted names no longer receive the same authenticated existence or nonexistence statement.

Cybersecurity 23 Sep 2026 5 min read

Aggressive DNSSEC Caching Reuses Authenticated Denial Proofs

A conventional DNS negative cache remembers a negative result for a specific query. DNSSEC adds richer material to that response: NSEC and NSEC3 records can cryptographically prove that names or record types do not exist. RFC 8198 permits a validating resolver to reuse those cached proofs for later queries that fall inside the proven space. This behavior is called aggressive use of the DNSSEC-validated cache. It can suppress repeated authoritative lookups for names whose nonexistence is already established by validated data. The mechanism is more than a performance optimization: fewer unnecessary queries also reduce exposure of misspelled or random names beyond the recursive resolver and can absorb part of the load created by random-QNAME traffic.

Cybersecurity 15 Sep 2026 7 min read

NSEC3 Trades DNSSEC Name Exposure for Operational Cost

NSEC3 Trades DNSSEC Name Exposure for Operational Cost A signed DNS zone has to authenticate absence as well as presence. When a resolver asks for a name that does not exist, a DNSSEC-validating resolver needs cryptographic evidence that the negative answer was not forged by an intermediary. The original NSEC mechanism supplies that evidence by linking existing names in canonical order. That design has a side effect: the links expose names. Following NSEC records can reveal much of a zone even when ordinary DNS queries do not provide an enumeration interface.