When deciding to sign a zone with DNSSEC, one of the initial decisions is which “deny” system to use. There are currently two, the original and simpler called “NSEC”, and a later one that is much more complex, called “NSEC3”. (Why is there no “NSEC2”? For the same reason that there is no IPv5).

The recommendation has always been to use NSEC3 only in special cases, generally oriented to registries (TLD) that require for legal or privacy reasons to keep the list of subdomains secret. NSEC3 is also attractive for this type of records because it allows you to partially sign your zone, using the opt-out technique, which allows you to gradually grow in zone and record size, as subdomains activate DNSSEC, sacrificing a little security.

But hey, each administrator has the reasons and decides which technique he will use.

If you decide to use NSEC3, you must immediately define other important variables, such as signing algorithm, key size, etc; and among some of those decisions is to define two parameters that have to do with the “salting” of the names: number of iterations and size of the salt, as well as the regular change of this last value.

This is cryptographic information that allows greater security to avoid the discovery of the names of a zone. In general, signing software comes with reasonable default values, and in a large number of installations these values are not modified.

However, a concern has recently begun to put limits on these two values. Security analysis by cryptographic experts have considered that it is not necessary to have these salt parameters or iterations in most zones, so the current recommendation is: zero the iterations, and use an empty salt. It is considered that the security gain of setting higher values is minimal, and it has the disadvantage of demanding high processing from the resolvers that must validate the records in that zone.

Although the current standard has somewhat exaggerated theoretical limits, and nothing prevents the use of large values, the problem is that now the resolvers are who can in turn prohibit higher values by implementation, which can mean high processing and high response times to resolve and validate domain names in these zones. Nothing prevents them from protecting themselves against unreasonable values.

This is how last month (March 2021), we already have the first open source resolver software that has decided to set a maximum limit of 150 iterations for validity with NSEC3 [1] (Update: Bind9 also limits to 150 iterations[4]). If a domain currently indicates more than 150 iterations, that resolver will refuse to validate it, and will mark the zone as “insecure”, that is, just as if it did not have DNSSEC active!

Work is already under way at the standards level in the IETF [2] to write a document that analyzes this situation, and talks [3] on the subject have been held at DNS conferences.

We therefore recommend that you check how many iterations you are doing in your domain, if you are using NSEC3. Any query for the type “NSEC3PARAM” returns this value in the third number, for example this domain “example.cl” has 250 iterations and the salt value “4240ECEF733CBFBD”:

$ dig -t nsec3param example.cl + short 1 0 250 4240ECEF733CBFBD

The recommendation is to lower the value of the number of iterations to 0 (actually this number is the “extra” of iterations, since there is always 1), and leave the salt empty (value “-”). For example, the Bind tool “dnssec-signzone” accepts the parameters “-3 - -H 0” that achieve this result.

References: - [1]: “validator: downgrade NSEC3 records with too many iterations”, Knot Resolver 5.3.1 (2021-03-31), https://gitlab.nic.cz/knot/knot-resolver/-/tags/v5.3.1 - [2]: “Guidance for NSEC3 parameter settings”, draft document in IETF, https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/ - [3]: “NSEC3 Iterations etc. High Counts and opt-out considered harmful, avoid fixed salt”, talk from ICANN DNSSEC Workshop, (PDF), https://cdn.filestackcontent.com/content=t:attachment,f:%228.%20Viktor%20Dukhovni%20NSEC3-ICANN.pdf%22/m2OglWwSR2o9L4m6Xsgo - [4]: “DNSSEC responses containing NSEC3 records with iteration counts greater than 150 are now treated as insecure”, Notes for BIND 9.16.16 (2021-05-20)