Updating NSEC3 parameters prevents problems with validating resolvers
Nearly half of signed .nl domains still using outdated configurations
RFC 9276 advises against further use of certain features of NSEC3, the DNSSEC security mechanism that provides digitally signed – and therefore trustworthy – DNS responses to queries about non-existent records.
It's now 2 years since RFC 9276 was published, and its recommendations have been picked up by many domains. However, nearly half of all the signed .nl domain names that use NSEC3 have yet to implement the advice. We therefore advise registrars and authoritative name server operators to check the NSEC3 configurations of their domain names, and to update them where necessary. The iterations parameter should be set to '0' and the salt parameter to '-'. Over the year ahead, we'll be looking into the possibility of adapting our DNSSEC incentive scheme to promote compliant configurations.
NSEC and NSEC3
NSEC is an essential component of DNSSEC security. It provides a mechanism for giving cryptographic assurance that a given DNS record really doesn't exist: so-called 'authenticated denial of existence'. The way it works can be summarised as follows. The zone file is sorted, and digitally signed NSEC records are added, e.g. for a.example.nl and c.example.nl. Returning those NSEC records in an intelligently compiled DNS response enables a validating resolver to deduce that, for example, b.example.nl doesn't exist. In order to do so, however, the name server has to disclose that a.example.nl and c.example.nl do exist.
That approach has the drawback that malicious actors and other inquisitive parties have easy access to information that can be used for undesirable purposes, such as inventorying all the (existing) names in a zone: a trick known as 'zone walking'.
NSEC3 resolves that problem (in principle) by hashing (i.e. digitally scrambling) the names, and putting the hashes in the NSEC records, rather than the names themselves. NSEC3 also makes it possible to add a salt to each domain name and a number of additional iterations to performance of the hash function. Those features make straightforward zone-walking impossible.
More complex, but no more secure
However, experience has shown that the use of salt and additional iterations makes NSEC3 more complex without actually enhancing security. Each extra hash function iteration performed does nevertheless require additional cryptographic computation power.
Against that background, RFC 9276 recommends that extra iterations shouldn't be performed, and that salt should no longer be used. In the NSEC3PARAM record, domain registrants and authoritative name server operators should therefore set the iterations parameter to '0' and the salt parameter to '-'. We reconfigured the .nl zone in line with RFC 9276 (and made a number of other improvements) at the end of 2022.
Extra iterations
Although it's now 2 years since RFC 9276 was published, nearly half of all the signed .nl domain names that use NSEC3 have yet to implement the RFC's advice. Data gathered by SIDN Labs shows that 46 per cent of the names are configured to perform 1 or more additional iterations. In a few cases – 3 in a thousand – the configuration requires 100 iterations, which can cause problems for validating resolvers.
Figure 1: 46 per cent of the signed .nl domain names that use NSEC3 are configured for 1 or more extra iterations. [Source: SIDN Labs]
Check your NSEC3 settings
We therefore advise registrants and authoritative name server operators to check the NSEC3 configurations of their domain names, and where necessary to update them as soon as possible. The iterations parameter should be set to '0' and the salt parameter to '-'.
NSEC3 settings are saved in the NSEC3PARAM record, which is (only) used by the authoritative name server when signing the zone. In a compliant configuration, the NSEC3PARAM record will be something like this:
example.nl IN NSEC3PARAM 1 0 0 -
In that example, the specified parameters (in the order they appear) are:
Hash algorithm: value is always 1 (SHA-1)
Flags: value is 0, unless the 'Opt-Out' flag is set for unsigned delegations (in which case the value is 1)
Extra iterations: value should now always be 0
Salt: should no longer be used, so value is '-'
For details, see RFC 5155 (which defines NSEC3); for specific guidance on setting the parameters referred to above, see the documentation for your server software [e.g. BIND named, PowerDNS Authoritative Server]. Remember: the new settings will not take effect until you re-sign your zone. Anyone wanting to quickly check whether their current settings are correct can use a utility such as the one here:
https://mxtoolbox.com/nsec3param.aspx
"During the coming year, we'll be working with SIDN Labs and stakeholders to establish whether our DNSSEC incentive scheme should be adapted to promote compliant configurations," says Product Owner Chris Faber. "In due course, we may make compliant configurations a qualification requirement for the incentive." Account Manager Jeroen Wolsink adds that "We will of course discuss any proposed changes with internal and external stakeholders before acting."