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

Improvements
1

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.

2

Just a short update here. By talking to my registrar’s support I found that the real blocker was that my MIAB’s IP showed up for both name servers located at the sub-domains ns1. and ns2.

I ended up fixing this issue by setting up an external secondary dns and logged into MIAB’s dashboard and created a custom dns entry for the ns2. sub-domain.

:point_up: After this change goes through your MIAB status page will probably show a little warning that the ns2. sub-domain doesn’t point MIAB’s IP. However, that’s to be expected since we’ve purposely overriden this behavior.

Shout out to this guide which helped me: Guide: How to setup NSD as a secondary nameserver for Mail-in-a-Box . Additionally, it also helped to inspect my MIAB’s NSD config by looking inside /etc/nsd without changing anything.