Best practices: keeping your DNSSEC infrastructure secure and reliable

DNSSEC will soon mark its twentieth anniversary (RFC 4033/4034/4035 published in March 2005) but it was not really until the signing of the root zone in July 2010 that a start could be made on deploying the technology. Domain name operators (including Afnic) had already been experimenting well before that date, so they were all ready and set to enable top-level domains to be signed fast and chains of trust to be established from the root, as well as offering our respective communities the possibility of signing their own zones.

We will not be dealing here in any detail with the DNSSEC technology itself, as this subject has already been covered by Afnic in several articles in addition to a themed paper, a comprehensive guide to deploying DNSSEC and a dedicated training course. This article is aimed first and foremost at those who have already taken the leap and are wondering about what comes next. “Yes, I’ve signed my zone, but now what?”

Signing your zone is not an end in itself, but it’s very often the start of a long journey. Fifteen years ago this operation may have represented a challenge, but these days things are much easier. Adopting this technology has been made much simpler by the development of tools offering tried and tested functionalities that are easier to use on the one hand, and on the other hand by the sharing of experience and the dissemination of knowledge to an ever-wider audience.

So far so good, but once you’ve signed, what aspects of DNSSEC should be watched carefully, which ones should be developed, and what questions should you be asking yourself?

• Are the key algorithms used fifteen years ago still just as relevant?
• Haven’t the settings recommended when DNSSEC was launched evolved?
• Does changing the keys regularly really help?
• Should I be concerned about the impact of work on quantum computers on current encryption methods? And is there anything I can do to prepare?

These are the kinds of considerations we intend to address here, attempting to provide answers and suggesting actions to make sure signed zones are kept up to date with the latest recommendations. For this we shall rely on various reference documents, in particular RFC 8624 (Algorithm Implementation Requirements and Usage Guidance for DNSSEC), published in 2019 and specifying which existing algorithms should no longer be used and which ones should. Cryptography being a constantly evolving science, a new version of this RFC is already in the course of being adopted by the IETF (draft-ietf-dnsop-rfc8624-bis).

The signing algorithms to choose in 2024

Let’s take a look at the latest developments in terms of recommended algorithms (paragraph 3.1 of RFC 8624)

Although cryptographic algorithms such as RSA-MD5, DSA and SHA-1 have long been used in the field of computer security, they are no longer considered reliable and effective due to their vulnerability. Similarly, the use of GOST R 34.10-2001 (mnemonic ECC-GOST), which was obsoleted in 2012, is also discouraged. The case of RSASHA512 is somewhat different in that it is considered just as effective as RSASHA256, but in fact has not seen wide deployment and the extra security compared with RSASHA256 does not warrant having two algorithms with similar properties.

Afnic considers that only algorithms with a “MUST”, “RECOMMENDED” or “MAY” implementation status in the RFC 8624 table should be used for signing. This still leaves the choice of five algorithms, namely: RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14), ED25519 (15) and ED448 (16).

These algorithms are used by 99% of the signed zones in the TLDs that we manage. Which is great, but what risks are the users that operate the remaining 1% running?

Beyond the reliability and effectiveness considerations referred to above, using algorithms designated as obsolete exposes you to the risk of their no longer being usable in all or part of the system in the near future. For example, if you use ISC’s BIND tool on a recent operating system such as RHEL 9 or its derivatives, you might be surprised by the result of certain commands.

Let’s try for example to create a key for the fr zone using RSASHA1-NSEC3-SHA1 (7):

> dnssec-keygen -a NSEC3RSASHA1 -b 1024 fr

dnssec-keygen: fatal: unsupported algorithm: NSEC3RSASHA1

This means that if an administrator uses this algorithm on a RHEL 8 operating system and decides to upgrade their system to RHEL 9, they will first have to change the key algorithms in order to be able to continue to apply their key/signature procedures on the updated system.

For the moment, we are not (yet) formally prohibiting the algorithms that RFC 8624 advises against, but for a few months now we’ve been removing algorithms from the list of those that can be selected when adding a DS-type record for the zone in cases where the algorithm is no longer used at all in that zone. For example, for a domain in the fr zone it is still possible to use nearly all the algorithms listed above, whereas for domains in the museum zone, only the five acceptable algorithms can be selected.

Afnic’s advice:

• If your zone is signed with an algorithm other than RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14), ED25519 (15) or ED448 (16), change the keys as soon as possible, choosing an algorithm from the list proposed.
• Elliptic curve cryptography algorithms have certain advantages over RSA-type algorithms. We recommend opting for ECDSAP256SHA256 (13), which is the algorithm used by Afnic and by numerous TLD operators, or ED25519 (15) which looks set to become the preferred algorithm in the near future.

Parameter settings for proving non-existence

This topic has already been the subject of an article (RFC 9276, Afnic adopts the no-salt diet). If you’re not familiar with this concept and with NSEC/NSEC3-type records, we encourage you to re-read it.

In a nutshell, NSEC3 proposes a technique for proving non-existence (RFC 5155) which, in contrast with NSEC, does not rely on existing domain names but uses hashing, calculation of which can be controlled with the aid of several parameters. One of these allows you to define the number of times this hash will be calculated (in addition to the initial calculation), while another allows you to add salt (a piece of random data) to the calculation of this hash. Several subsequent studies have shown that the extra security provided by these changes was not sufficiently significant to justify the cost entailed by these additional calculations in terms of resolution systems.

Furthermore, recent work has indicated that this additional processing can be used to attack DNS resolvers by exhausting their resources (CPU, memory). A malicious user could deliberately configure a zone (or find an existing one) with excessive NSEC3 settings (thousands of iterations, maximum salt length of 255 characters). A substantial volume of requests for domain names that do not exist in this zone would subsequently require the resolver to make a disproportionate number of calculations in order to respond to them. This type of attack is the subject of a CVE (Common Vulnerabilities and Exposures) report (CVE-2023-50868).

The good news is that the recommendations on settings allowing the calculation of the hash used in NSEC3-type records appear largely to have been followed. Specifically, whereas in 2022 fewer than 2% of the signed zones that had chosen NSEC3 complied with these rules, now the percentage is close to 90. That leaves just over 10% of zones that use sometimes extravagant values for the number of iterations.

Afnic’s advice:

• If you use NSEC3, follow the recommendations of RFC 9276.

Choice of a good algorithm for the DS published in the parent zone

As well as DNSSEC keys, RFC 8624 also provides recommendations on the choice of algorithm for the DS-type record published by the parent zone (the zones operated by Afnic in this precise case). Even allowing for the fact that from the outset there was much less choice than in the case of keys, the table proposed leaves very few alternatives.

In fact, only the choice of SHA-256 (2) seems reasonable. Logically one would expect DS records of the SHA-1 (1) type to be very much in the minority given that in 2006, RFC 4509 was published, introducing a new type of algorithm (SHA-256) which states that

Implementations MUST support the use of the SHA-256 algorithm in DSRRs. Validator implementations SHOULD ignore DS RRs containing SHA-1 digests if DS RRs with SHA-256 digests are present in the DS RRset.

whilst it is true that for several years, normal practice was always to have 2 DS records per KSK, specifically one SHA-1 type and one SHA-256 type, today things have changed and in very many cases only SHA-256 type DS records are to be found. For example as regards the root zone file, 98% of TLDs publish only SHA-256 type DS records.

As regards Afnic, and specifically the fr zone, 99.5% of domains with DS type records have at least one SHA-256 type. However, tens of thousands of these domains also have a SHA-1-type DS record.

In contrast with the situation as regards the keys used to sign the zones, Afnic could potentially carry out a clean-up operation and make SHA-1-type DS records disappear. This could be done in a number of stages:

• For domains with one SHA-256-type DS record and another SHA-1-type, once we have verified that they both have the same key, we could eliminate SHA-1-type DS records from these domains in our zone files.
• For domains with only a SHA-1-type DS record, we would first create a new SHA-256 DS record then eliminate the SHA-1-type DS record some time later.

A current analysis of the data shows that with very rare exceptions (incorrectly signed zones), all domains could apply this algorithm for cleaning up SHA-1 DS records.

That said, there are currently no plans for this type of operation. But other registries have used similar approaches, with success.

On the subject of DS records, we should add that when analysing the data we noticed a few rare cases in which domains were associated with five or six DS records. While there is currently no prohibition of this kind, it is important to know that work is under way to determine a clear limit (there is none in the current RFCs) and that a possible limit of three DS records has been brought up on several occasions. There is nothing to suggest that this number will necessarily be chosen, but if this type of zone should ever behave unusually during DNSSEC validation, check carefully to make sure no new rule has been introduced in this respect.

Afnic’s advice:

• Remove or replace SHA-1/GOST-type DS records and instead use SHA-256.
• Limit the number of DS records to three (aside from KSK rollovers, one is generally enough for the vast majority of zones that don’t use standby KSKs).

The case of the root zone

The signing of the root zone in 2010 is what really activated validation at the level of resolvers. The key generated at the time (referenced under the name KSK-2010 and having the key tag 19036) was used until October 2018. So we had to wait eight years for the first KSK replacement to be finalised. In 2016, KSK-2017 (key tag 20326) was generated to replace KSK-2010 and was activated in 2018. The algorithm used for the key (RSASHA256) was retained, since it had not been particularly called into question and elliptic curve-based algorithms were still too recent and not yet widely deployed on DNS servers. In any case, there was a question mark over them at the time and no-one was offended by this choice, especially since this key rollover was the first for the root zone and was carried out without disrupting the Internet.

It was this fear, of disrupting the Internet, that led to the wait being so long. Numerous discussions subsequently took place aimed at persuading IANA to carry out this type of operation more regularly, based on the principle that “practice makes perfect”. Some people, on the other hand, advocated that there was no need to change this key. This point of view certainly has its supporters; after all, key rollovers affect all the resolvers in the world. Granted, but what would happen if tomorrow, as a result of a security failure, this key had to be changed willy nilly and nobody was capable of doing so or even of measuring the consequences of the change?

IANA finally yielded to this logic and decided to carry out KSK rollovers every three years. KSK-2017 is more than three years old, but several events have delayed the launch of its replacement (COVID lockdowns, replacement of the type of HSM used, etc.), so in the end it was not until 2024 that the next KSK was created. It has yet to be published in the DNS but has already been published on IANA’s website (https://data.iana.org/root-anchors/root-anchors.xml). You will see that the same algorithm is still used. The key will be activated in October 2026.

The next key should be generated in mid-2027 (KSK-2027) and activated in October 2029. At this stage IANA has not yet confirmed that this key might have a different algorithm (so maybe for KSK-2030?) With things moving at this pace, we might well wonder whether elliptic curve-based algorithms will be the panacea or whether we will have newly developed and standardised algorithms that can supposedly withstand quantum computers.

Afnic’s advice:

• A KSK rollover that doesn’t go as planned can have consequences, so change KSKs “regularly”, and possibly change algorithm too so as to test your procedures and make sure they will function properly if this kind of operation ever has to be carried out in an emergency.

Post-Quantum Cryptography (PQC) and DNSSEC

Although the use of RSA and elliptic curve-based algorithms is recommended, there is nonetheless a fly in the ointment. Toward the end of the 1990s, an American mathematician called Peter Shor described an algorithm, now eponymous, that would allow prime factors to be broken down into products exponentially faster than the best currently known algorithm running on a classical computer. Shor’s algorithm could be exploited to crack both RSA-based and elliptic curve-based keys. We say “could be” because to be able to execute this algorithm you would need access to a quantum computer with enough power.

While such computers do exist, there are various complex physical problems to be overcome before they can be widely deployed. As a result, nobody can say from what date the algorithms used for DNSSEC will have become vulnerable. But even if we have another 30 years before reaching this situation, we have seen with the prudent changes of root keys and algorithms that making major changes to DNSSEC without endangering the stability of the DNS infrastructure will take many years. Which is why work started some time ago to find replacements for today’s cryptographic algorithms. In 2022, the National Institute of Standards and Technology (NIST) provided a list of new algorithms resistant to Shor’s algorithm (see HERE our article on the subject). From then on IETF engineers began work on anticipating and proposing adaptations to the protocols we use and are currently focused on analysing the impact on the current infrastructure of the use of the algorithms proposed to evaluate the foreseeable changes. For example, one consequence of these new algorithms will be an increase in the size of keys and signatures. Regarding this last-named point, the Falcon-512 algorithm is the best performer thanks to the compactness of the signatures it produces. As regards the size of keys, however, the approaches studied can be quite disruptive, as with the use of Merkle trees which allow data to be processed in condensed form rather than voluminous keys (Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC) but which, on the other hand, require constant ZSK rollovers.

On 27 November 2024, a group of national agencies involved in cyber-security from 18 European Union Member States (including ANSSI, the French Cybersecurity Agency) published a joint statement on transitioning to post-quantum cryptography. The scope of application is of course wider than the subject that interests us here, but the recommendations are of the same order, namely to start getting ready now for the long and sometimes difficult transitions that this will imply.

So the next few years in our ecosystem are set to be somewhat exciting in view of the coming developments, and Afnic will continue publishing articles so as to keep its readers up to date.

Afnic’s advice:

• Even if from afar, keep an eye on advances in the field of post-quantum cryptography so as to anticipate and not to have to make hurried adjustments to your systems.
• And a tip that applies to all the points addressed in this article: use Zonemaster and DNSViz tools to analyse your signed zones. They are updated regularly and apply the latest recommendations on DNS/DNSSEC.