Zeros Are Heroes: NSEC3 Parameter Settings in the Wild

This article is a summary of our recent research paper on this topic.

DNSSEC relies on public-key cryptography to add integrity and authentication to plain DNS. When done in offline mode, resource record sets are signed so that signatures can be returned along with responses. This does not return signatures when queried for non-existent data, because there is nothing in the zone file to sign.

To address this problem, the NSEC (Next Secure) resource record is used to prove that nothing exists between two names sorted in the canonical order. When receiving the NSEC record, a resolver can easily verify if the queried domain lies within the corresponding range.

Every NSEC record reveals two domain names, thus potentially enabling the enumeration of all domains in a zone file. RFC 5155 tries to solve this issue by replacing plain domain names with their hashes, this time inside a new NSEC3 record. All the hash computation parameters are stored in a dedicated NSEC3PARAM record, including the number of additional iterations N (note that 1 iteration is implied) and the salt S. Aside from hashing, RFC 5155 also specifies a so-called "opt-out" flag, allowing delegations to unsigned zones to opt out of having a dedicated NSEC3 record. This ensures that big delegation-oriented zones (such as TLDs) can avoid generating NSEC3 records for unsigned delegated domains.

Over time, several issues arose with the original NSEC3 specification. Most importantly, it was argued that due to the mostly unencrypted nature of exchanges and techniques such as passive DNS, all domains must be assumed to be publicly known, entirely defeating the purpose of hashing them. This is especially true considering that modern GPU-based attacks are capable of breaking those hashes in any case.

RFC 9276 was published to acknowledge those problems and provide the list of best practices, as summarised below in Table 1. These guidelines become critical in light of a recently discovered DoS attack that becomes worse as N increases. We therefore set out to analyse whether the recommended NSEC3 parameter settings are enforced in the wild.

Authoritative name servers

We analysed over 302 million registered domains across 1,449 TLDs. Out of these, 26.6 million and 1,354 were DNSSEC-enabled, respectively. We further keep 15.5 million domains and 1,302 TLDs that support NSEC3. We evaluate items 1 to 5 on this dataset.

The use of NSEC3 is prevalent - more than half of DNSSEC-enabled registered domains implement RFC 5155, which does arguably not fulfil Item 1. This ratio is even higher for TLDs, as almost all of them use NSEC3, most likely driven by the need of the opt-out flag. The number of additional iterations is set to 0 for 12.2 % of NSEC3-enabled domains only, although the great majority of them rarely exceeds 25. On the long tail, however, a few have N set to 500. The vast majority of TLDs, on the other hand, uses 0 additional iterations.

Only 8.6 % of NSEC3-enabled domains strictly comply with Item 3 (SHOULD NOT use a salt), but virtually all have at most 10 bytes of salt. Among TLDs, salts of 0 and 8 bytes are most common. Setting the opt-out flag for small zones is not recommended as per Item 4 and it seems to be largely followed - only 6.4 % of NSEC3-enabled registered domains set it in any returned NSEC3 record. On the contrary, 85.4 % of TLD do set the opt-out flag, as allowed for large and sparsely signed zones by Item 5.

Looking at name server operators, we found that the top 10 serve at least 77.7% of NSEC3-enabled domains. Only three of them comply with Item 1 for a fair share of served domains.

Resolvers

We then check how validating resolvers treat domains with various numbers of additional iterations. We detail all the test subdomains at https://rfc9276-in-the-wild.com. In total, we located 1.9 million open and 2.5K closed resolvers in IPv4 and IPv6 address spaces, the latter identified using the RIPE Atlas platform. We further kept 112K open and 1.9K closed DNSSEC validators.

Overall, 59.9 % of the validating resolvers implement Item 6 from Table 1, meaning that they treat domains with high iteration values as insecure. Major resolvers were updated in 2021 to return insecure responses above 150 additional iterations. The other two common delimiting iteration values are 100 and 50, although less frequent than 150. The value of 50 coincides with the behaviour of resolver implementations patched to protect from CVE-2023-50868.

Fewer validating resolvers (18.4 %) return SERVFAILs starting from some threshold X, meaning that they implement Item 8 from Table 1. The first SERVFAIL mostly occurs at the additional iteration value of 151. The other two common starting points for SERVFAILs are 1 (418 resolvers) and 101 (92 resolvers), the great majority of those being open IPv4. While the limit of 100 only renders unreachable a tiny subset of domains (see Figure 1) the limit of 0 prevents access to 87.8 % of NSEC3-enabled domains if requesting non-existing records or subdomains.

More generally, less than 18 % of open resolvers returning insecure or SERVFAIL responses accompany them with an extended DNS error INFO-CODE 27, indicating a low support of Item 10. Therefore, a client cannot distinguish a failure due to exceeding the iteration limit from the one returned for other reasons.

Conclusions

We revealed that 87.8 % of NSEC3-enabled domains do not follow the best current practice on NSEC3 parameter settings. Our measurements also show a high concentration of non-compliance among a few DNS name server operators, suggesting that those alone could substantially improve the deployment of RFC 9276. More generally, the recently discovered CVE and the operational complexity of the hashed authenticated denial of existence raise questions on its usefulness altogether.