RFC 9276, Afnic adopts the no-salt diet

In essence, it alerted us to the fact that our DNSSEC configuration no longer conformed to the standards in force and that we ran the risk of our TLDs no longer being correctly validated by the DNS resolution services.

Here is an extract:

So what is this RFC referred to in this message, and should you be worried about possible disruptions of the resolution service in the near future? These are the two questions we will attempt to answer here.

We will also review the current practices of our partner registries and in the .fr zone and to present the developments we had envisaged carrying out soon.

Presentation of RFC 9276 (Guidance for NSEC3 Parameter Settings)

This document, published in August and adding to the thirty or so RFCs dealing directly with DNSSEC, makes new recommendations on the parameter settings of signed zones that have opted for NSEC3 technology. Although ICANN’s email is a reminder not to forget to address this subject, it did not introduce this RFC or these recommendations for the first time. Indeed, the subject comes up regularly in discussions in the technical groups of the bodies in which we participate (DNS-OARC, IETF, etc.) and its formalisation as part of an Internet Draft has been under way for more than a year now. More specifically, what does this RFC 9276 say?

When signing a zone in the context of DNSSEC, we are offered two techniques for resolving the problem of proof of non-existence: NSEC (RFC 4034) and NSEC3 (RFC 5155). Standardised some years after NSEC, NSEC3 is a response to the main criticism of NSEC, namely that it was extremely easy to enumerate the content of a zone. Today, with open data, this may seem like an argument from another era, but at the beginning of this century it was a subject that affected many domain name registries.

So if this aspect is no longer so crucial, why then should we nevertheless switch to NSEC3? The answer can be found in the possibility of activating the “opt-out” option, which is not available in NSEC. It allows registries to sign only as many zone records as it needs as opposed to having to sign them all. The difference in terms of CPU resources, storage and bandwidth is considerable for zones containing only a minority of records to be signed. It is mainly because of this functionality that NSEC3 is favoured by many players in our industry, despite its complexity, to the detriment of NSEC.

What you need to know about NSEC3, and this is the purpose of this document, is that where NSEC uses an unencrypted domain name in the registration to perform the proof of non-existence, NSEC3 uses hashing. To make the process a bit more complex still, the calculation of this hash depends on several parameters for which RFC 9276 proposes values to be favoured.

The number of iterations

The calculation method of the hash repeats the operation several times in order to make dictionary attacks more difficult. (A dictionary attack consists in systematically and automatically trying all “guessable” names). A parameter allows you to select the number of additional iterations to be made. Even if the value is zero, at least one calculation will be carried out.

The use of NSEC3 since it was introduced and recent work seem to indicate that the benefits of a number of iterations beyond the first one are not sufficient to justify the additional processing costs induced when generating these records with each NXDOMAIN response from the authoritative name server or during DNSSEC validation in resolvers.

The authors of this RFC therefore advise setting this parameter at zero.

Salt

In addition to the number of iterations, it is possible to add a salt value to influence the hash. This too is aimed at making dictionary attacks more difficult. But in this case, given that the calculation uses the complete domain name (FQDN), an attacker is already obliged to have one dictionary for each zone.

The advantage of adding an additional salt value is therefore debatable, particularly if this is “never” changed (a change means the whole zone has to be resigned).

The authors of this RFC therefore advise not using salt.

Recommendations

The implementation of these recommendations is aimed at two types of audience. Firstly, zone publishers. These operators are strongly advised to carefully consider the advantages of NSEC3 over NSEC and not to use NSEC3 unless NSEC does not meet their needs. If NSEC3 is chosen, they are recommended not to use either salt or additional iterations (we shall see presently how this advice is taken into account in reality.)

Secondly, DNSSEC validating resolvers should gradually reduce their requirements for these two parameters to “reasonable” levels. There is no calendar at this stage, but given the sensitive nature of the subject it is likely to be discussed and therefore clarified over the course of the next few months. Since last year, the majority of the software solutions used (Bind, Knot, Unbound, PowerDNS, etc.) have already had limits in place as default values for these parameters. These limits are not as extreme as those proposed here, and the fact that they are available does not mean that they are the latest versions deployed or that these default values will be maintained, but a change is under way. In the case of “over-limit” parameters, these servers could, for example, decide to return a SERVFAIL type response to clients when processing NSEC3 type records. It is this specific point (paragraph 3.2 of RFC 9276) that could have operational consequences for zones not following these recommendations.

So do we need to be worried? The answer is yes (a bit)… but not immediately. Indeed, even though there is nothing to prevent operators of this type of resolver from applying the recommendations of the RFC’s two authors to the letter, they are very unlikely to do so unilaterally. The more so as RFC 8914, which is recommended for responding to certain cases, has not yet been completely implemented by providers of DNS solutions. Furthermore, these providers would have to agree to propose coordinated action, such as in the past with the DNS Flag Days.

That said, perhaps it is time to verify these parameters in your zones so as to use so-called “reasonable” values. We shall see presently that this is the case in the great majority of instances but that some zones nonetheless use unusual values that it would be appropriate to adjust.

Review of root and TLDs

During October we carried out an analysis of all the top level domain names.

Of the 1,487 TLDs studied, the vast majority, 1,363, were signed. More than 97% of these signed zones have opted for NSEC3. The opt-out has been exercised by 86% of these. As for the number of additional iterations, although the maximum is 25 for a very few TLDs, 40% use the recommended parameter of zero, while in any case 99% have set the number of additional iterations at ten or less. As for salt, for 99% of zones its value does not exceed 8 bytes, 40% having already adopted the no-salt regime recommended by our two authors. If we look in a little more detail, namely at ccTLDs only, this adoption rate is somewhat lower, 23% as opposed to 40%.

Unsurprisingly the zones that we operate conform to the standard type of TLD. They are all signed, they all use the opt-out and NSEC3, with 4 bytes of salt and a single additional iteration.

Review of the .fr zone

Given that we have exhaustive knowledge of the list of signed zones for this TLD, we were able to analyse the approximately 750,000 zones concerned. The profile that emerges is somewhat different from that of the TLDs.

Although NSEC3 remains the favoured choice of these zones at 89%, the opt-out has been exercised by only a very small minority, fewer than 1%. As for the number of iterations, only 1.5% use the recommended value of zero. While nearly all the zones have ten or less additional iterations, several hundred others have more than 100 (the maximum being 200). For these, changing could become a matter of urgency since certain software publishers have already set the maximum number of iterations accepted at 150 (the value can be modified, but it is the default value). Lastly, as for the TLDs, even though salt values of 64 bytes exist, the vast majority are equal to or less than 8 bytes.

Changes to come, what we have decided

As has been planned for several months, in the next few weeks Afnic will modify the parameter settings of the zones it operates to eliminate salt and will not include additional iterations in the calculation of the hash values.

We will, however, keep NSEC3 and the opt-out. With this option, the .fr zone contains 14 million records; without it, there would be 10 million more, thus going from 650 MB to 1.4 GB (the increase in size is not proportional since the additional NSEC3 and RRSIG records are of substantial size).

Conclusion

Although this type of RFC has no legal force, it describes how NSEC3 should be configured. As such it will be progressively integrated into the various DNS solutions used by validating resolvers. Afnic for its part will continue with its work on this subject and will continue to take the necessary measures to inform its community if we detect any zones affected by the coming changes. For the moment, we strongly advise operators of zones with parameters far removed from the usages of the majority of players in the sector to review them in order to avoid any unpleasant surprises.