What does "NSEC3 parameters not RFC 9276 compliant" mean (iterations and salt)?

DNSSEC needs a way to prove that a name does not exist (authenticated denial of existence). NSEC3 does this with hashed record names, which also makes it harder to "walk" the zone and list every name in it.

NSEC3 has two tuning parameters that used to be set defensively:

• Iterations — how many extra times each name is hashed.
• Salt — a random value mixed into the hash.

The old thinking was that more iterations and a salt made zone-walking harder. RFC 9276 (August 2022) settled the matter: they do not meaningfully help, and they cost you.

What RFC 9276 requires

• Iterations = 0 (no extra hashing).
• Salt = empty (shown as - in the NSEC3PARAM record).

So a compliant zone publishes:

example.com. IN NSEC3PARAM 1 0 0 -

(hash algorithm 1 = SHA-1, flags 0, 0 iterations, empty salt.)

Why 0 and empty

• Zone enumeration is not really stopped. A determined attacker can still recover names offline; iterations and salt only slow them down marginally. If you truly need to hide names, that is a different tool (on-the-fly "white lies" signing), not high iterations.
• Iterations cost everyone CPU. Every validating resolver re-hashes on every negative answer, so a high count is a denial-of-service vector against your own zone.
• A salt buys nothing and complicates key rollovers — changing it means re-signing the whole zone.
• Modern resolvers reject it. Unbound 1.19+ and BIND 9.19+ treat high iteration counts as insecure or bogus, so an over-hardened zone can break validation entirely.

How to check

Look at the NSEC3PARAM record. Anything other than 1 0 0 - (a non-zero iteration count or a non-empty salt) is non-compliant. IntoDNS.ai flags this on a scan and names the exact parameter at fault.

How to fix

Re-sign the zone with iterations 0 and an empty salt:

• PowerDNS: pdnsutil set-nsec3 example.com '1 0 0 -', then pdnsutil rectify-zone example.com.
• BIND (dnssec-policy): set nsec3param iterations 0 salt-length 0;.
• Cloudflare: already compliant — it signs with 0 iterations and no salt automatically; nothing to do.
• Managed DNS / registrar: if your provider sets a salt or iterations for you (some, like TransIP, historically did), ask them to re-sign with the RFC 9276 defaults, or move signing to a provider that does.

This is a low-severity hardening item, not an outage — but on strict modern resolvers a badly over-hardened zone can fail validation, so it is worth getting to 1 0 0 -.