The Next DNS Root Key Roll Is Underway, and Adoption of the New Key Is Dangerously Low

Cryptographic keys are never meant to last forever. Breaking a private key is not mathematically impossible; it is computationally infeasible, meaning an attacker would need an enormous amount of processing power and time. If a key is used for many years, an attacker has those same years to keep trying. That is why key lifetimes, algorithm choices, and key sizes must be regularly re-evaluated against the growth of computing power, including the possible arrival of cryptographically relevant quantum computers. For secrets that must stay protected for 20 years, post-quantum algorithms may be needed; for secrets with a five-year lifetime, production quantum computers are less of a near-term concern. In the Domain Name System Security Extensions (DNSSEC), which adds digital signatures to DNS lookups so users can trust the answers, most keys have short lifetimes of a few months to a year or two, so they do not yet need post-quantum protection.

But regular key rollover is still essential. All cryptographic keys used in DNSSEC should be replaced periodically, both to limit exposure and to give operators practice with the rollover process. There is no single correct interval: rolling every week is too short, while leaving a key in place for twenty-five years is unwise. A good operational practice is to introduce a new key into the zone's DNSKEY record, which holds the public keys for that DNS zone, and leave it there for at least one DNS cache lifetime before switching over. Alternatively, a zone can use a new key immediately by publishing multiple RRSIG records (digital signatures) so that each DNS record is signed by both the old and new keys; however, care must be taken that DNS responses do not grow beyond the 1,210-byte UDP packet fragmentation threshold, because larger responses can be dropped by some networks. Recursive resolvers sometimes apply their own cache lifetimes rather than the zone's guidance, so a conservative introduction period before deleting the old key is wise. The detailed operational practices are described in RFC 6781 and RFC 7583.

The one major exception is the root key of the DNS, called the Root Key Signing Key (KSK). This key signs the root zone of the internet's naming system, and every DNSSEC-validating resolver must have a copy of its public key as a trust anchor. The first root KSK served for eight years; its successor, KSK-2017, has now been in service for just under eight years as of May 2026. The long lifetime is not by choice but by necessity: there is no convenient way to introduce a new KSK value and have it rapidly incorporated into the trust anchor sets of all validating resolvers. Instead, IANA, which administers the root zone, publishes an incoming key long before it is used, signs it with the current key (a process known as 'old signs new'), and waits an extended period for resolvers to pick it up. The stated objective lifetime for the root KSK is nominally five years, but practical experience extended this; the first roll was performed on 11 October 2018. If such extended lifetimes remain common practice for IANA, the need to move to significantly larger post-quantum algorithms and keys will arrive sooner. The next roll is underway: the incoming key, KSK-2024, was published on the IANA website in July 2024 and added to the root zone's DNSKEY record in January 2025. IANA plans to use KSK-2024 to generate the root zone's digital signature in October 2026, replacing KSK-2017.

To track whether resolvers have adopted the new key, researchers use two different measurement techniques. The first, described in RFC 8145, asks resolvers to signal which keys they trust when they send queries to root servers. A resolver can embed the key tags in a special query name, such as _ta-4f66-9728, which means it trusts keys with tag values 20326 and 38696, or it can include the tags in an EDNS option. RFC 5011 specifies an add hold-down time of 30 days or the original TTL of the first trust point DNSKEY RRSet, whichever is greater, so that a resolver must see at least two validated records containing the new key before accepting it. Verisign analyzed these signals and reported in March 2025 that all reporting resolvers still trusted KSK-2017, which was expected until that key is revoked in early 2027. Around 0.5% of resolvers still trusted KSK-2010, even though it had been revoked in 2019, likely because of outdated operating system updates. A small population began trusting KSK-2024 in July 2024, right after the key was published in the IANA trust anchor file. The largest jump occurred 30 days after the key was added to the root zone's DNSKEY record, which matches the automatic update timing defined in RFC 5011. A small rise during that first month likely came from resolvers configured manually. However, this data only counts reporting resolvers, not the number of users behind each resolver, and it misses resolvers that do not support the signalling mechanism at all.

To get a user-centric view, APNIC uses a different method described in RFC 8509, the Root Key Trust Anchor Sentinel. Instead of asking resolvers to signal root servers, this approach places a special left-most label in a DNS query name. The resolver recognizes the label and returns a response based on whether it trusts a particular key. For example, a query to root-key-sentinel-is-ta-20326 returns the normal answer if the resolver trusts that key, and SERVFAIL (a DNS error) if it does not. The inverse label root-key-sentinel-not-ta-20326 returns SERVFAIL if the key is trusted, and the normal answer if not. APNIC's ad-based measurement system sends these queries to a collection of end users every day. The test uses three labels: not-ta-20326 and is-ta-20326 first verify that the resolver performs DNSSEC validation and supports the sentinel mechanism; the third, is-ta-38696, checks whether the resolver has loaded KSK-2024 into its trust anchor set. Only samples where the first two tests return the expected responses are counted as 'reporting users'.

The results are surprising. Although the RFC 8145 resolver-level data suggested that reporting resolvers had adopted KSK-2024 in March 2025, the RFC 8509 user-level measurement tells a different story. In April 2026, 13 months after the 30-day introduction timer for KSK-2024 had finished, fewer than 20% of users behind DNSSEC-validating resolvers had added KSK-2024 to their local trust anchor set. This means that if the root KSK roll happened immediately, the vast majority of users on validating resolvers would suddenly see DNSSEC validation failures and be unable to reach many websites. The discrepancy may arise because many resolvers that validate DNSSEC do not support the sentinel mechanism, or because the resolver population is different from the user population. The measurement has limitations: the advertisement-based test uses two URLs, and a validating resolver that supports the sentinel returns a DNSSEC-signed answer for the is-ta