Rolling the root key | APNIC Blog

In cryptography, no cryptographic key is eternal — breaking a key is not a computationally impossible problem, it’s just a computationally infeasible problem! In practice, it’s infeasible to assemble a large enough pool of processing capability and enough time to try every possibility to derive the private key value. But if a key is used for an extended period of time, then a potential attacker has the same extended time to attempt to break the key.Limiting the time a key is used and limiting the time that you require the encrypted material to be considered a secure secret can help in ensuring the secrecy of the material within those bounds. The outcome is that cryptographic material, like cryptographic keys, algorithms, and key sizes, needs to be regularly reevaluated and revised in light of the evolution of computational capacity and the duration of the intended secrecy of the material. A cryptographically acceptable algorithm and key should not be breakable using available (and projected available) computational resources over the period of time that you wish to maintain the integrity of the information that has been digitally signed or encrypted.The requirement to factor in projected computational capacity has become more challenging. To protect the key used to encrypt information for a period of 20 years, a common lifetime for secrets, we need to consider whether quantum computers will form part of the arsenal of accessible computation capability in that period. If the answer is ‘yes’, then we must immediately consider how to transition to so-called post-quantum cryptographic algorithms. On the other hand, if the intended lifetime of a secret is five years or less, then the construction of cryptographically relevant quantum computers for use in production environments is less of a concern.For DNSSEC — and most of the DNS infrastructure — the algorithms used by DNSSEC do not have to meet these tougher post-quantum cryptographic standards at present. The intended lifetime of use of DNSSEC keys is generally around several months, or a year or two at most.The single exception to this observation is the root key of the DNS, the Root Key Signing Key (KSK). The first KSK was in service for eight years, and its successor has now been in service for just under eight years. The long key lifetime of the Root KSK is because there is no convenient way to introduce a new KSK value and have it rapidly integrated into the Trust Anchor (TA) sets of all DNSSEC-validating DNS resolvers.

The chosen solution is to use this KSK for extended periods and take more time to introduce new keys into the root zone before their use. If such extended KSK key lifetimes are a common practice for the DNS Root Zone administrators at the Internet Assigned Numbers Authority (IANA), then the prospect of shifting to significantly larger post-quantum algorithms and keys is getting closer and closer!What does this general consideration of the transient nature of cryptographic keys imply for DNSSEC? It means that all cryptographic keys used in the DNSSEC framework should be rolled regularly. What ‘regularly’ means can be interpreted differently by different folk, but the chosen algorithm and key length should be resistant to attack for at least the lifetime of use of the key. Key rolls should happen regularly so that the operators of the DNS zone have practice with the key roll process.Rolling a DNSSEC key every week is probably too short an interval, but leaving a cryptographic key in place for twenty-five years is equally unwise. However, there is no single interval that applies to all DNS zone administrators. A good operational practice is to introduce a new key into the zone’s DNSKEY record, and then leave it in place for at least one DNS cache lifetime interval before switching over to the new key. It is also an option to use a new key immediately, by choosing to publish multiple RRSIG records in the signed zone, with each Resource Record being signed by each key. Care should be taken when adding more material to DNS responses so that they do not bloat beyond a useful UDP packet fragmentation threshold of 1,210 bytes in size.It’s also useful to bear in mind that the cache lifetimes defined in a zone are merely guidelines, and recursive resolvers have been observed to apply their own lifetimes to cached DNS material. A conservative approach should be taken to defining a suitable introduction period before deleting the old key and all records signed by that key.RFC 6781 DNSSEC Operational Practices, Version 2, from December 2012, and RFC 7583 DNSSEC Key Rollover Timing Considerations, from October 2015, both provide essential further reading on this topic.However, an entirely different set of considerations applies to the Root KSK used by the root zone of the DNS. There is no upper-level context in which the KSK is published that can determine its acceptance.

Instead, the new KSK must be introduced into the root zone and signed by the current KSK (‘old signs new’). Then an extended period is required to allow DNSSEC-validating clients sufficient time to pick up and trust the incoming key. RFC 5011 Trust Anchor Update contains some guidance for this process. It states: “The add hold-down time is 30 days or the expiration time of the original TTL of the first trust point DNSKEY RRSet that contained the new key, whichever is greater. This ensures that at least two validated DNSKEY RRSets that contain the new key MUST be seen by the resolver prior to the key’s acceptance.” RFC 5011The stated objective for the operational lifetime of the Root Zone KSK is nominally five years, but practical experience has extended this period, with the first roll undertaken on 11 October 2018. I analysed this key roll in a previous post.The next KSK key roll is underway as of May 2026. This is not a change of algorithm, but simply a change of the private key value. The incoming KSK (KSK-2024) was published on the IANA website in July 2024 and added to the root zone’s DNSKEY Resource Record in January 2025. The IANA plans to roll the KSK in October 2026, when it will be used for generating the root zone’s DNSKEY Resource Record digital signature in place of the existing key, KSK-2017.How are we going with this KSK roll? Have all DNSSEC-validating recursive resolvers learned of KSK-2024 by now and incorporated this key into their TA set?How can we measure this behaviour?Trust signal: RFC 8145 measurementThere are two techniques we can use to peer into the Internet’s DNS infrastructure and find out which DNS resolvers have added KSK-2024 to their local TA set.The first is described in RFC 8145 Signalling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC). In this technique, the resolver embeds the key tags of its trusted keys in queries that are sent towards the authoritative servers for the root zone.

One way is to place the tag values of all trusted keys into a query name (that is, a query name of ‘_ta-4f66-9728‘ indicates that the resolver trusts keys with tag values of 20326 and 38696). An alternative method is to embed the trust key tag values into an edns-key-tag option in queries.This information is visible in the log of queries managed by the operators of root servers. An analysis of this RFC 8145 signal received by a root server operator is shown in Figure 1.Figure 1 — A sampling of resolvers, and which KSK(s) they have configured in their TA, as of 3 March 2025. Source: Verisign blog.Verisign noted in March 2025 that all of the reporting resolvers have KSK-2017 configured as their TA (green line at the top of Figure 1). We expect it to remain like that until after KSK-2017 is revoked, scheduled to occur in early 2027. In March 2025, there were still quite a few resolvers (~0.5%) that trusted KSK-2010 (purple line in Figure 1), even though it was revoked in 2019. Perhaps this was due to its lingering presence in operating system software updates.There was a small population of resolvers that began including KSK-2024 in their TA configuration in July 2024, right after the key was published in the IANA TA file on their website. The large jump occurred 30 days after the key’s inclusion in the root zone’s DNSKEY Resource Record. This behaviour is consistent with the timeline as specified by RFC 5011. The small rise in this initial 30-day period appears to be related to a small number of DNS resolvers that configured their trusted KSKs manually.What the data in Figure 1 does not show is the population of users who are using these recursive resolvers.

Obviously, some DNSSEC-validating recursive resolvers are used heavily, sometimes by millions of end users, while others, including the one on my local laptop, are used by just me!When the March 2025 figures show that up to 90% of reporting resolvers have added KSK-2024 to their TA set, that does not readily map to an estimate of the end user population that is served by these recursive resolvers, nor the population of end users who may be affected by an immediate roll of the KSK.Also, this data does not show the population of DNSSEC-validating recursive resolvers that are not using this TA signalling mechanism. This implies that it’s challenging to place this data in the larger context of all DNSSEC-validating recursive resolvers and what this means for end users.Key Sentinel: RFC 8509 measurementRFC 8509 A Root Key Trust Anchor Sentinel for DNSSEC, proposes a different approach where the signal of a recursive resolver’s trusted keys is folded back and sent to the querier, rather than onward towards a root zone server. The approach involves a left-most label of a DNS query name, and requires the DNS resolver to recognize this label and generate a response based on the resolver’s set of trusted keys, as shown in Table 1.LabelKey is trustedKey is not trustedroot-key-sentinel-is-ta-<key-tag>return original answerreturn SERVFAILroot-key-sentinel-not-ta-<key-tag>return SERVFAILreturn original answerTable 1 — RFC 8509 measurement responses.We use APNIC’s ad-based measurement system to pose these queries to a collection of end users every day. What we are after here is not to identify individual validating recursive resolvers, but to quantify the population of end users who are located exclusively behind DNSSEC-validating resolvers, where the resolver has so far failed to trust KSK-2024.The test we are using has three queries, as shown in Table 2.