RFC 9276 states that the NSEC3 parameter for additional hash iterations must be set to zero

Hi!

I’m using a DNS checker tool from the registrar responsible for the .no TLD. I know that such tools vary in quality. But this one seems to try hard at being standards compliant.

For my domain it currently throws an “Verify NSEC3 parameters” error. See report here (you can select English in the top right).

(The report also contains a bunch of other complaints related to a secondary dns I intend to phase out. Nevermind those ones.)

Apparently RFC 9276, argues that the NSEC3 hash iteration parameter must be set to zero for zone publishers. This parameter only dictates additional hash iterations, so the NSEC3 protection would still be in place.

Excerpt from the RFC on best practises for zone publishers:

NSEC3 requires greater computational power (see Appendix B) for both authoritative servers and validating clients. Specifically, there is a nontrivial complexity in finding matching NSEC3 records to randomly generated prefixes within a DNS zone. NSEC mitigates this concern. If NSEC3 must be used, then an iterations count of 0 MUST be used to alleviate computational burdens. Note that extra iteration counts other than 0 increase the impact of CPU-exhausting DoS attacks, and also increase the risk of interoperability problems.

Based on this RFC, should the default NSEC3 parameter for additional hash iterations be set to zero in a future MIAB update?

Personally, I’ve started moving some domains to a new registrar that follows this exact DNS checker tool to the letter. And their system for updating name servers blocks updates when encountering errors such as this.