Disable advanced features of NSEC3 security technology for DNSSEC

NSEC

NSEC, short for Next Secure, is part of DNSSEC (specified in RFC 4034, section 4). It provides a way of attaching digital signatures to DNS responses regarding non-existent records: what's known in the industry as 'authenticated denial of existence'. The response types that NSEC covers are NXDOMAIN responses (for non-existent domain names) and NODATA responses (for non-existent record types relating to existent domain names). It is, of course, impossible to sign all non-existent domain names, so each NSEC record specifies a range between two existent domain names. If, for example, you ask for the A record for the non-existent name gopher.example.nl, the response is an NSEC record stating that there are no domain names between ftp.example.nl and mail.example.nl. NSEC records are created and signed when you sign your zone (usually roughly doubling the size of the zone file). So, when a validating resolver requests a non-existent host name, it gets back a signed NSEC record for the interval within which the requested name falls. The resolver can therefore be sure that the name doesn't exist. It should be stressed that the mechanism described above is the basic model. As you can read in this article, operators such as Cloudflare have come up with all sorts of clever tricks for generating NSEC3 records for dynamic zones (with DNS responses generated on-the-fly using a database). The problem with NSEC is that it makes it easy to discover all the host names in a zone. By firing off a smart series of non-existent domain name lookups, you can compile a full set (linked list) of a zone's NSEC records, defining all the interval boundaries (i.e. the domain names that do exist). That is often undesirable from a security viewpoint.

NSEC3

NSEC3, defined in RFC 5155, was developed to prevent that kind of 'zone walking' or 'zone enumeration'. The basic principle is that, instead of stating actual domain names in your signed responses, you state their hashes (digitally scrambled versions of the names). A client that asks for a non-existent host name therefore gets back a signed NSEC3 record for the interval between two hashes, within which the hash of the requested host name falls. That involves the zone operator first hashing the zone's NSEC interval boundaries and then sequencing them for signing. A client that validates an NSEC3 record doesn't therefore check the domain name itself, but first generates the domain name's hash and then checks that the hash falls within the NSEC3 record's boundaries. The use of hashes prevents the straightforward compilation of a list of existing domain names. Even with hashes, however, it's possible to discover all the domain names in a zone by using a dictionary table (a table of pre-generated hashes of all common labels). To prevent that as well, a salt is added to each domain name and a number of extra steps (iterations) are added to the hash function. The relevant settings are the same for the whole zone and are recorded in the new NSEC3PARAM record. By regularly changing the salt (simply a random string), you can prevent the compilation of a reusable dictionary table for your zone. For background information about how NSEC and NSEC3 work, and about their history, see RFC 7129.

Best Current Practice

Nevertheless, some aspects of the design and use of NSEC3 are questionable. For one thing, many host names are not secret, such as www, mx1, api, etc. What's more, adding extra hash iterations doesn't make the mechanism fundamentally more secure. It simply means that both hackers and legitimate actors, such as the operators of validating resolvers serving numerous users and the administrators of large signed zones, have to deploy proportionally greater computational power. In most cases, the use of salts also seems unnecessary: hashes are generated from full domain names (FQDN), implying that dictionary tables need to be zone-specific in any case. Moreover, frequent salt rollovers represent a very minor additional challenge for a would-be hacker; in a relatively stable zone, most previously discovered labels will remain valid. With those points in mind, a Best Current Practice (BCP) document entitled 'Guidance for NSEC3 parameter settings' has been drafted. Although the document is yet to be finalised, its basic message will be that domain operators should stop using both the extra iterations and the salt.

No longer implemented

Miek Gieben is a DNSSEC expert, author, prolific DNS software developer and former Technical Advisor at SIDN. During his time in the latter role, he took a close interest in NSEC3 (being, amongst other things, co-author of RFC 7129). Miek endorses the recommendations of the new BCP document. Indeed, he is generally no fan of NSEC3 and has opted to stop implementing NSEC3 in his CoreDNS software.

Miek's main reasons for dropping NSEC3 are that it's complex and no longer provides effective protection against the problem it was developed to prevent. As long ago as 2014, for example, a group of researchers succeeded in mapping two thirds of the NSEC3-secured domains in the .com zone. Using a single graphics processing unit (GPU), it took the researchers just 4.5 days to complete the task.

Our advice: set extra iterations and salt to zero

If you are a domain name registrant or operator and you want to use NSEC3, we advise doing as the new BCP recommends and setting both the extra iterations and the salt to zero. Indeed, it's possible that the use of zero settings may at some stage be added to our DNSSEC incentive scheme. TransIP recently pre-empted the new advice by setting the iterations parameter to zero. The test algorithms used by the Internet.nl portal have also been aligned with the latest recommendations.