DNS Root KSK Roll: Is KSK-2024 Widely Trusted?
The DNS root KSK rolls on 11 October 2026. See what KSK-2024 adoption data reveals, how DNSSEC trust is measured, and what network operators should check.
The DNS Root Key Is Rolling. How Ready Is the Internet?
Based on measurements reported on , ahead of the planned 11 October root key rollover.
A cryptographic key change in one part of the DNS can usually be authenticated by a key above it in the hierarchy. The DNS root has no parent, so replacing its key is a different kind of operation. Resolvers have to learn to trust the incoming key before they use it to validate the root zone's DNSKEY records. If they don't, DNSSEC validation can fail for the users behind those resolvers.
The next root Key-Signing Key (KSK) rollover is scheduled for 11 October 2026. The incoming key, KSK-2024, has been published for a while, but publication isn't the same thing as adoption. Validating recursive resolvers still need to add it to their local trust-anchor sets.
Measurements published by APNIC show a mixed picture. Around 90% of resolvers that report trust-anchor information through one method had added KSK-2024. A separate user-facing measurement found KSK-2024 trusted in about 70% of tests that appeared to support its sentinel method. Those figures come from different samples, so you can't just mash them into one readiness number. Here's what the rollover involves, what the measurements can (and can't) tell you, and what DNS operators should check.
Why the root key rollover needs special handling
DNSSEC adds signatures to DNS data so a validating resolver can check that the answer is authentic and wasn't altered. It depends on a chain of trust. A resolver starts with keys it already trusts, then verifies signatures down the DNS hierarchy.
For most DNS keys, there's a parent key that can authenticate a replacement. A zone's Key-Signing Key can sign for its Zone-Signing Key. A parent zone can publish a signed Delegation Signer record to help authenticate a child zone's key. The root is different: there's no parent zone above it that can vouch for a new root key.
The old key has to introduce the new one
Because the root can't rely on a parent, the rollover uses an overlap period. The existing root KSK signs the new KSK in the root zone's DNSKEY record set. A validating resolver that sees the new key can verify that signature using the old key it already trusts. It can then add the incoming key to its local trust-anchor set after the required hold-down period.
This rollover process is laid out in RFC 5011, Trust Anchor Update. The hold-down rule is meant to ensure a resolver sees the new key in validated DNSKEY data more than once before accepting it. The period is at least 30 days, or longer if the original time-to-live requires it. In a normally operating resolver, trust-anchor updates should happen automatically.
That automation is the whole point. A root KSK rollover shouldn't require people to manually edit settings on laptops or home routers. But automation only helps if resolver software supports the update process, can fetch the right DNS data, and isn't configured in a way that prevents the new key from being accepted.
What is changing in 2026
This is a key-pair replacement, not a change to the cryptographic algorithm. IANA published KSK-2024 in July 2024, and it was added to the root zone's DNSKEY record set in January 2025. The planned rollover date is 11 October 2026, when the new KSK is expected to be used to generate the DNSKEY record-set signature.
The relevant key tags are 20326 for the current KSK-2017 and 38696 for KSK-2024. A key tag is a short identifier used in DNSSEC operations; it isn't the key itself. For the rollover to go smoothly, validating resolvers need to trust the new key before they rely on signatures made with it.
If a resolver hasn't learned the incoming key, it may not be able to validate the root DNSKEY data after the transition. Depending on what the resolver has cached and how it's implemented, users behind it could see DNS lookup failures, often shown as a SERVFAIL response. That's an operational compatibility risk, not proof that the key change is a security incident.
What the adoption measurements actually show
There's no single global dashboard that can directly count every validating resolver and every person who depends on it. Instead, researchers infer trust-anchor adoption using signals from resolvers or from response behavior that reflects the trust anchors a resolver has loaded. APNIC's report uses two approaches, each with a different measurement unit.
RFC 8145: resolvers report their trusted key tags
Under RFC 8145, a resolver can signal which DNSSEC trust anchors it knows about in queries it sends toward authoritative root servers. The signal can show up in a query name or via an EDNS option. Root server operators can observe these signals in query logs and estimate how many reporting resolvers include particular key tags.
The Verisign data cited in the APNIC report shows that, as of July 2026, around 90% of reporting resolvers had added KSK-2024 to their trust-anchor set. That suggests many resolvers are on track. But it's not a count of 90% of all recursive resolvers, and it doesn't say what share of internet users those resolvers serve.
A resolver on a large broadband or mobile network may handle millions of users. A smaller resolver might cover a single household or a single person. Treating both as one resolver weights the sample equally, even though the user populations can differ hugely.
RFC 8509: test the behavior from the user side
The second method uses the root key trust-anchor sentinel described in RFC 8509. Instead of sending a report to a root server, a test sends specially constructed DNS queries through the user's configured resolver. The resolver's response indicates whether it supports the sentinel and whether it trusts a specified key.
The test first checks for sentinel support using KSK-2017, key tag 20326. If the expected responses show up, the measurement can classify the tested connection as being behind a resolver that supports the mechanism. A follow-up query checks for KSK-2024, key tag 38696.
APNIC reported around 16 million ad-based tests per day during its measurement windows. About six million daily tests appeared to be behind DNSSEC-validating resolvers, and around 1.8 million provided a clear RFC 8509 support signal. Among tests that appeared to support the sentinel, around 70% reported that KSK-2024 was trusted.
These numbers aren't interchangeable with the RFC 8145 result. One method counts resolvers that report trust-anchor tags; the other samples user connections and tests resolver behavior. They use different populations, different collection methods, and different denominators. The 90% and 70% figures aren't necessarily contradictory - they're answering different questions.
The low-adoption networks deserve attention, not a verdict
APNIC's report also listed networks with at least 1,000 tests showing RFC 8509 support but comparatively low observed acceptance of KSK-2024. The examples below illustrate the range:
| Network | ASN | Reported KSK-2024 adoption |
|---|---|---|
| Telefonica de Costa Rica | 262202 | 49.4% |
| Hutchison Telecoms, Sri Lanka | 17470 | 48.7% |
| Allo Communications, United States | 15108 | 16.4% |
| Vodafone Libertel, Netherlands | 33915 | 12.7% |
| Reliance Jio, India | 55836 | 2.5% |
| Unitel, Angola | 37119 | 1.4% |
| Vodafone-Oman, Oman | 212661 | 0.9% |
These are measurement results, not an audit of an ISP's entire DNS setup. A network can run multiple resolver platforms, and a sample may cover only part of its users or infrastructure. Read the table as a signal to investigate, not proof that every resolver operated by the named network is unprepared.
Where the measurement has limits
Measurement results only help when you understand the denominator. APNIC's ad-based system sends queries to a sample of end-user connections; it doesn't identify individual resolvers and it isn't a census of DNS traffic. The same resolver may show up in many tests, while other resolvers never appear. User distribution, network configuration, and test compatibility all affect what the sample represents.
The sentinel method also depends on support for RFC 8509. If a resolver doesn't support the mechanism, it won't produce the same clear signal about its trust-anchor state. It shouldn't automatically be treated as lacking KSK-2024. The RFC 8145 reporting method has coverage constraints too: resolvers that don't emit the signal won't show up in the reporting-resolver percentage.
There's also a practical distinction: validating isn't the same as reporting. APNIC's daily measurements included many tests that looked like they were behind DNSSEC-validating resolvers, but only a smaller subset produced a clear RFC 8509 signal. If you combine those categories into one headline number, it's easy to make an uncertain estimate look definitive.
The network-level table needs similar caution. Some entries have large test volumes, while others sit close to the minimum sample threshold. The results can reflect resolver behavior observed from a particular set of users and devices, rather than a network-wide configuration policy. It would be a mistake to use a low percentage by itself to declare an operator negligent or to predict a precise number of affected customers.
None of this means the measurements don't matter. They highlight where technical follow-up is worth doing - especially where the sample is large and adoption looks low. Think of them as monitoring signals, not a substitute for resolver logs, configuration review, and direct operational testing.
What DNS operators and users should do
If you operate a recursive resolver, don't treat a public adoption chart as your readiness check. Verify the resolver software and the trust-anchor state in your own environment. The question isn't whether "the internet" is mostly ready. It's whether the resolvers your users rely on have learned and accepted KSK-2024.
Resolver operator checklist
- Confirm DNSSEC validation is enabled as intended. Identify which resolver pools validate DNSSEC and whether any pools use custom trust-anchor configuration.
- Check automatic trust-anchor maintenance. Confirm your resolver implementation supports RFC 5011 updates and that update processing isn't disabled or blocked by local policy.
- Verify the new key is present. Check the resolver's local trust-anchor state for KSK-2024, key tag 38696, using the tools and documentation for your specific resolver software.
- Test representative paths. Run checks from different sites, resolver clusters, and customer networks. A test from one endpoint doesn't prove every pool is in the same state.
- Review logs and monitoring. Make sure you can detect DNSSEC validation failures, unexpected
SERVFAILresponses, and trust-anchor update errors around the change. - Prepare a rollback and escalation path. Know who can investigate a resolver failure and how you'll communicate with upstream providers or affected customers. Don't disable DNSSEC validation as a first response unless you understand the security implications and have a controlled incident plan.
The APNIC report points operators to a Cloudflare-operated page for testing sentinel behavior. You can also review the relevant RFCs and your resolver vendor's operational guidance. A web test can provide a helpful external view, but it doesn't replace checks inside your own infrastructure.
What an ISP customer can do
Most home users don't control their ISP's recursive resolver, so they usually don't need to change their router just because a root key is rolling. If you see DNS lookup failures around the rollover, start by separating a DNS resolution problem from a broader connectivity outage. Testing with another trusted resolver can help narrow the cause. But switching DNS providers isn't a universal fix - it comes with privacy, security, and policy trade-offs.
If your provider appears in a low-adoption result, contact its support or network operations team with a specific question: have its DNSSEC-validating resolvers accepted KSK-2024, key tag 38696? Pointing to the measurement can prompt a review, but treat it as a reason to check - not as proof that something has already failed.
For organizations that run their own resolvers, the same idea applies: check your own setup. A company might use a managed DNS service for office devices, a separate resolver in cloud environments, and an ISP resolver for remote staff. Your actual operational risk depends on those dependencies, not just your company's primary network.
Conclusion
The root KSK rollover is a planned maintenance step in DNSSEC, but because it sits at the top of the DNS trust chain, resolver readiness matters. The available measurements suggest many resolvers had learned KSK-2024 before the scheduled change, while some sampled networks showed much lower adoption. Neither measurement method provides a complete census, and neither should be treated as a direct count of affected users.
For operators, the action is straightforward: verify the trust-anchor state on the systems you run, confirm automatic updates are functioning, and monitor DNSSEC validation through the transition. For users, there's usually nothing to configure. If you run DNS infrastructure, use the RFC 5011 guidance and your resolver's documentation to check readiness rather than relying on assumptions about what "most of the internet" is doing.