NSEC3
type 50RFC 5155NSEC3 (type 50, RFC 5155) is the zone-enumeration-resistant successor to NSEC. Instead of linking actual domain names, NSEC3 links SHA-1 hashes of domain names in sorted order. An attacker querying for non-existent names receives hashed NSEC3 records that prove non-existence but cannot be trivially reversed to discover zone contents. NSEC3PARAM records specify the hashing parameters (algorithm, iterations, salt). Offline dictionary attacks against NSEC3 hashes remain possible, which led to the development of NSEC3 opt-out and later NSEC5 (in development).
Details
NSEC3 prevents zone enumeration by hashing domain names before exposing them in denial-of-existence records.
Hashing process: For each name in the zone, compute: SHA-1(salt || owner_name || iterations) The resulting hash (base32hex encoded) becomes the NSEC3 owner name. NSEC3 records link these hashed names in sorted order, just like NSEC links real names.
NSEC3PARAM record: Published at the zone apex. Specifies: Hash algorithm (1 = SHA-1, the only currently defined value) Flags (0 or 1 -- opt-out flag) Iterations (additional hash rounds, higher = slower brute-force) Salt (random bytes to prevent pre-computed dictionary attacks)
Iterations controversy: High iteration counts slow down legitimate resolvers as well as attackers. RFC 9276 (2022) recommends iterations=0 for new deployments because modern hardware makes even thousands of iterations insufficient against offline GPU attacks, while the performance cost to resolvers is real. Use a long random salt instead.
NSEC3 opt-out flag: When the opt-out flag is set, unsigned delegations (NS records without DS records) are not individually hashed. This dramatically reduces the NSEC3 record count in large TLD zones (.com has millions of delegations, most unsigned). Opt-out is common in TLD zones; less common in regular zones.
Known weakness: NSEC3 hashes can be cracked offline with GPU dictionary attacks, especially with common domain name patterns and low iteration counts. NSEC5 (work in progress, uses VRFs) aims to fix this completely but is not yet standardized.
Checking DNSSEC validation: dig A example.com +dnssec delv example.com A https://dnssec-analyzer.verisignlabs.com/
Wire format fields
| Field | Description |
|---|---|
| Hash Algorithm | 1=SHA-1 (the only defined algorithm in RFC 5155). |
| Flags | Bit 0 = Opt-Out flag. If set, unsigned delegations are not covered by this NSEC3 record. |
| Iterations | Number of additional hash rounds (0 recommended per RFC 9276). |
| Salt | Random bytes prepended to hashed name to prevent pre-computed attacks. Variable length, 0-255 bytes. |
| Next Hashed Owner Name | Base32hex-encoded SHA-1 hash of the next name in sorted order. |
| Type Bit Maps | Same as NSEC: bitmap of record types that exist at the unhashed name. |
Zone file example
; NSEC3PARAM at zone apex – specifies hashing parameters
example.com. IN NSEC3PARAM 1 0 0 AB12CD34 ; algo=1, flags=0, iterations=0, salt=AB12CD34
; NSEC3 records (owner name is base32hex hash of real name)
2VPKU5URPHBF1BSBKVH.example.com. IN NSEC3 1 0 0 AB12CD34 (
7QIDK6E4RLNV1FTCG2SN ; next hashed name
A MX RRSIG
)
; The owner name "2VPKU5URPHBF1..." is SHA-1("AB12CD34" + "mail.example.com")
; Check NSEC3 in a real zone:
; dig NSEC3PARAM example.com +dnssec
; dig A nonexistent.example.com +dnssec → returns NSEC3 denial