DNSSEC signed zones - best practice guidance relating to NSEC3 signing and validation
DNSSEC-signed zones offer protection against response spoofing to both DNSSEC-validating resolvers and authoritative DNS zone operators who chose to sign their published zones.
NSEC and NSEC3 are the mechanisms within DNSSEC used to provide proof of non-existence of names. This is achieved by a DNSSEC-signed assurance that between two signed names, no other names exist.
NSEC3 uses hash mechanisms to avoid disclosure of the bounding names themselves, otherwise it is possible to establish a list of all names in a zone by 'walking' the non-existence bounds chain (NSEC). Since most DNS names are well-known or easily guessable and not intended to be secret, the use of NSEC3 to hide zone contents is, for many operators, an unnecessary overhead.
NSEC3 configuration options provide two additional security mechanisms, largely now held to be ineffectual against a determined attacker, whilst at the same time adding processing overhead to DNS servers encountering them. These are:
IETF draft Guidance for NSEC3 parameter settings says:
NSEC3 records are created by first hashing the input domain and then repeating that hashing algorithm a number of times based on the iterations parameter in the NSEC3PARM and NSEC3 records. The first hash is typically sufficient to discourage zone enumeration performed by "zone walking" an NSEC or NSEC3 chain. Only determined parties with significant resources are likely to try and uncover hashed values, regardless of the number of additional iterations performed. If an adversary really wants to expend significant CPU resources to mount an offline dictionary attack on a zone's NSEC3 chain, they'll likely be able to find most of the "guessable" names despite any level of additional hashing iterations.
Furthermore, the use of NSEC3 iterations impose a significant computational overhead on DNSSEC-validating resolvers. Therefore updated best practice guidance for NSEC3 is to select an iteration value of 0, which in fact hashes the name once. (Zero additional iterations.)
The same draft also explains:
Salts add yet another layer of protection against offline, stored dictionary attacks by combining the value to be hashed (in our case, a DNS domainname) with a randomly generated value. This prevents adversaries from building up and remembering a dictionary of values that can translate a hash output back to the value that it derived from.
The difficulty with NSEC3 salt is that unless the salt value is changed extremely frequently (every hour or so), a long enough period of time is made available to would-be attackers in order to mount a dictionary attack on the zone to determine its contents. But changing the salt requires the entire NSEC3 chain to be replaced and re-signed - this is an expensive overhead on the primary/provisioning server and in zone content propagation/management.
This leads to an increasingly-held consensus that the use of NSEC3 salt serves no useful purpose, also addressed by the authors of Guidance for NSEC3 parameter settings :
Most users of NSEC3 publish static salt values that never change. This provides no added security benefit (because the complete fully qualified domain name is already unique). If no rotation is planned, operators are encouraged to forgo the salt entirely by using a zero-length salt value instead (represented as a "-" in the presentation format).
Changes introduced to BIND
The following versions of BIND (and newer) no longer support NSEC3 iterations greater than 150:
This means that:
- DNSSEC-validating resolvers will fall back to treating the zone as insecure (unsigned) if the zone operator is using NSEC3 records with greater than 150 iterations.
- Dynamic updates to a primary zone with NSEC3 iterations greater than 150 will be refused/rejected.
- DNSSEC signing tools will no longer accept iterations above 150.
- Zones already signed with NSEC3 iterations above 150 can be loaded by named, but a warning will be logged.
- Incoming zone transfers to secondary zone servers will log a warning with NSEC3 records with iterations greater than 150 are encountered.
Advice to Primary Zone Operators
- ISC engineers don't believe that NSEC3 iterations above 0 bring value, therefore our recommendation is ideally to use 0 (additional) iterations.
- Understand that modern DNSSEC-validating resolvers will be treating as insecure, any zones signed with NSEC3 iterations greater than 150.
- Don't use NSEC3 salt.
As DNS resolver providers adopt the latest recommendations and DNS resolver operators upgrade their servers, NSEC3 RRs with iterations above 150 will be disregarded and the proof of non-existence of names in the zone treated as if the zone was not DNSSEC-signed.
Advice to Secondary Zone Operators
- Be aware that modern DNSSEC-validating resolvers will be treating as insecure, any zones signed with NSEC3 iterations greater than 150.
- Check your logfiles for warnings - BIND will still accept inbound zone transfers for zones whose NSEC3 iterations exceed 150.
- Contact the owners of zones that you are hosting whose NSEC3 iterations exceed 150 to explain that that modern DNSSEC-validating resolvers will be seeing their zones as insecure.
Advice to Resolver Operators
- Upgrade to a current version of BIND.
Resolvers that are not DNSSEC-validating will not be affected by computational processing overhead when encountering query responses from authoritative servers with NSEC3 iterations exceeding 150, but we recommend keeping your version of BIND up-to-date for many other reasons, including ensuring that your server has the latest proactive and security fixes.