NSEC3 is configured with extra hash iterations
What this check looks for
Your zone asks every resolver to do extra repeated hashing on each lookup that finds nothing. It buys no real protection and makes your own nameservers a more attractive target.
Why it matters
Each iteration multiplies the work both your nameservers and every validating resolver must do for a non-existent name — which is exactly the query an attacker sends in a flood. Some resolvers now cap the iteration count and treat higher values as insecure, so a large number can cost you validation outright.
When the check passes, your report says: “NSEC3 uses zero extra iterations, as current guidance asks”.
What it costs your score
When this check fails it removes 5 points from your DNSSEC score, before the status, confidence and repeat multipliers are applied. DNSSEC carries a weight of 4 in the overall score.
It shares the dnssec.nsec3 family ceiling of 9 points: however many findings that family produces, together they cannot remove more than that from DNSSEC. One underlying problem showing up in several places is still one problem.
- Severity
- low
- Default confidence
- confirmed
- Status when triggered
- warn
- Deduction
- 5 points
- Family cap
- dnssec.nsec3 · 9
- Category
- DNSSEC
- Module
- Dns dnssec
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Set NSEC3 iterations to 0 and use an empty salt.
Extra iterations cost your nameservers and every resolver real work and protect nothing.
Change the NSEC3 parameters at your DNS host to 0 iterations and no salt.
Re-sign the zone so the new parameters take effect.
Most managed hosts expose this as a single setting; some now enforce 0 and the finding will simply not recur.
How to confirm it worked
dig +dnssec ‹domain› NSEC3PARAM — expect an iteration count of 0
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
‹domain› publishes NSEC3 with ‹iterations› additional iterations. RFC 9276 §3.1 is unambiguous: use zero iterations and an empty salt. The extra hashing was originally intended to slow down zone enumeration, and analysis since has shown it does not meaningfully do so, while the cost to resolvers and to your own servers is real and per-query.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.
Other dns dnssec checks
- The zone is signed with a deprecated algorithm
- Validating resolvers refuse to resolve the domain
- Signatures were read but not cryptographically verified
- The registry's DS record does not match any key in the zone
- The zone is signed but the registry has no DS record
- A DNSSEC key is shorter than the recommended size
- The zone's record names can be enumerated
- NSEC3 opt-out weakens proof for unsigned subdomains
- DNSSEC could not be checked
- A DNSSEC signature has expired
- A DNSSEC signature expires within seven days
- The zone publishes keys but no signatures