NSEC3 Record DNSSEC

The NSEC3 record provides authenticated denial of existence like NSEC, but uses hashed names to prevent zone enumeration (zone walking). This provides better privacy while still allowing cryptographic proof that a name or record type doesn't exist.

What Is an NSEC3 Record?

NSEC3 works like NSEC but replaces actual domain names with cryptographic hashes. Instead of revealing that "alpha.example.com" is followed by "beta.example.com", it shows that hash(alpha) is followed by hash(beta).

This prevents attackers from easily enumerating all names in a zone.

NSEC3 Record Format

2t7b4g4vsa5smi47k61mv5bv1a22bojr.example.com. 3600 IN NSEC3 1 0 10 aabbccdd (
                    4g3c2bq7o6bk82n8jls4j7b6sh3s2m89 A AAAA RRSIG )

NSEC3 Record Fields

How NSEC3 Works

1. Domain names are hashed: hash("www.example.com") → "2t7b4g4vsa5smi47..."
2. Hashes are sorted alphabetically
3. NSEC3 records chain the hashes together
4. When querying a non-existent name, the server:
   • Hashes the queried name
   • Returns the NSEC3 covering that hash range
5. The resolver verifies the queried hash falls in the gap

NSEC3 Parameters

NSEC3 parameters are published in an NSEC3PARAM record at the zone apex:

example.com.    NSEC3PARAM    1 0 10 aabbccdd

NSEC3 Configuration Options

Iterations

Number of times to hash. Higher = slower zone walking attacks but also slower legitimate resolution.

• RFC 9276 recommendation: 0 iterations (no extra hashing)
• Older guidance: 10-150 iterations
• Current best practice: Use 0 or very low iterations with no salt

Salt

Random value prepended before hashing. Originally meant to prevent precomputation attacks, but modern guidance (RFC 9276) recommends no salt for simplicity.

Opt-Out Flag

When set (flag = 1), allows unsigned delegations to be skipped in the NSEC3 chain. Used by large zones like .com to reduce signing overhead.

NSEC3 vs NSEC

NSEC3 Best Practices (RFC 9276)

• Use 0 iterations — Additional iterations provide minimal security benefit.
• No salt needed — Salts complicate rollover without significant benefit.
• Avoid opt-out if possible — Only use for very large zones.
• Consider aggressive NSEC3 — RFC 8198 allows caching NSEC3 for efficiency.

Troubleshooting NSEC3

Common issues and solutions:

• Validation failures — Check that NSEC3PARAM matches the NSEC3 records.
• Salt mismatch — All NSEC3 records must use the same salt as NSEC3PARAM.
• Chain gaps — Ensure complete NSEC3 chain covering all hashed names.
• Performance issues — Reduce iterations; modern guidance is 0.

Related Record Types

• NSEC3PARAM Record — NSEC3 zone parameters
• NSEC Record — Unhashed denial of existence
• RRSIG Record — NSEC3 signatures
• DNSKEY Record — Zone signing keys