# Understanding the DNS Root KSK Rollover: What You Need to Know Before October 2026
## Introduction
On October 11, 2026, the DNS root zone will undergo a key-signing key (KSK) rollover — only the second time this event has occurred in the history of the Domain Name System. The KSK serves as the cryptographic foundation of DNSSEC’s chain of trust, enabling DNS resolvers to verify that the responses they receive are authentic and unaltered. When this key changes, every validating resolver on the internet must recognize and trust the new key. If they do not, users may find themselves unable to reach websites even though those sites are functioning perfectly.
This article explains what a KSK rollover is, why it matters, how resolvers prepare for the transition, and what users can do to verify their own readiness.
—
## How DNSSEC Chain of Trust Works
When a DNS resolver looks up the address of a website, DNSSEC allows it to verify digital signatures attached to DNS records. These signatures guarantee that the data has not been tampered with and genuinely comes from the domain it claims to represent. However, verification alone is not enough — the resolver also needs to confirm that the public keys used to create those signatures are legitimate.
For a domain like `example.com`, this trust follows a chain upward: from the domain itself, to its parent zone (`.com`), and ultimately to the DNS root. Each level in the chain publishes a Delegation Signer (DS) record that contains a fingerprint of its child’s public key. For instance, `.com` publishes a DS record for `example.com`, allowing the resolver to confirm that domain’s key is authentic.
The chain must have a starting point. Since the root has no parent zone to provide a DS record, resolvers instead begin with a root public key — or its fingerprint — that they have been configured to trust. This trusted starting point is known as a **trust anchor**.
The root’s signing keys serve two distinct purposes. The **zone-signing key (ZSK)** signs the root’s DNS records, including the DS records for top-level domains like `.com` and `.org`. The **key-signing key (KSK)** signs the collection of public keys published by the root, known as the DNSKEY record set. A resolver uses its trusted KSK to verify the DNSKEY set, then extracts the ZSK from that set to validate the root’s other records.
—
## What Happens During a KSK Rollover
A KSK rollover replaces the cryptographic key pair that signs the root’s DNSKEY set. The old key is phased out and a new key takes its place as the authoritative signer. For the upcoming rollover, the new key is identified as **KSK-2024**, with key tag **38696**. It will take over from **KSK-2017**, which uses key tag **20326**.
If a validating resolver does not trust the replacement key when the switch occurs, it will be unable to verify DNSSEC signatures for any domain in the root zone. The result can be widespread and indiscriminate: websites under every top-level domain — `.com`, `.org`, `.net`, country-code domains, and others — may become unreachable for users whose resolvers have not updated their trust anchors.
This is not a hypothetical risk. Previous incidents involving failed DNSSEC checks at the TLD level have demonstrated that fully operational websites can become invisible to users when cryptographic validation fails. The root KSK rollover amplifies this concern because the root is the starting point for the entire chain.
—
## How Resolvers Learn the New Key
Resolvers that support automatic trust-anchor updates rely on **RFC 5011** to discover and accept new root keys. Under this mechanism, the root zone publishes the new KSK alongside the existing one within its DNSKEY set. The existing KSK continues to sign the set, so a resolver that already trusts the old key can use it to verify the records containing the new key.
Before accepting the new key as a trust anchor, the resolver must wait at least 30 days while continuously checking the root’s signed DNSKEY records. During this period, the new key must persist in the records the resolver examines. Only after this waiting period passes and the resolver successfully verifies the records containing the new key does it add the key to its set of trusted anchors.
For the current rollover, KSK-2024 has been published in the root’s DNSKEY set since January 11, 2025. This gives resolvers with automatic updates more than a year to discover and accept the new key ahead of the October 2026 transition. Each resolver’s personal waiting period begins on the date it first sees and successfully verifies the new key.
In some cases, software vendors choose to include the new key directly in their resolver’s built-in trust anchors rather than relying on automatic discovery. This approach was used during preparations for the first root KSK rollover in 2018, when it became clear that software upgrades and hardware migrations could cause resolvers to lose their learned trust-anchor state. Embedding the new anchor in the software itself prevents dependence on each resolver retaining a key it learned automatically.
—
## Checking Resolver Readiness with Trust Anchor Sentinels
Until recently, there was no practical way for ordinary users to check whether their DNS resolver trusted the upcoming replacement key. That changed with the introduction of **RFC 8509**, which defines the root key trust anchor sentinel. This protocol allows anyone to query a supporting resolver and ask whether it trusts a particular root key — using ordinary DNS queries directed at specially constructed domain names.
The sentinel mechanism works by publishing DNSSEC-signed address records under domains that encode questions about key trust. Two queries ask opposite questions: one asks whether the key is trusted, and the other asks whether it is not. A resolver that supports the sentinel protocol first validates the signed records, then either returns a normal response or replaces the answer with a `SERVFAIL` error, depending on whether it trusts the key in question.
For a resolver that supports the sentinel and does trust KSK-2024:
– A query for the “is trusted” sentinel returns a valid response containing IP addresses.
– A query for the “is not trusted” sentinel returns `SERVFAIL`, because the resolver deliberately rejects the question.
The opposite pattern indicates that the resolver does not yet trust the new key.
These sentinel labels can be used under any DNSSEC-signed domain. Testing infrastructure has been set up so that users can run these queries directly against public resolvers to get a snapshot of their resolver’s readiness. Additional checks within the test verify that ordinary signed names resolve correctly, that deliberately invalid DNSSEC names are properly rejected, and that the resolver responds to sentinel queries for the current root key. These safeguards help distinguish a meaningful result from a simple lookup failure or a resolver that does not support the sentinel protocol at all.
It is worth noting that browser-based tests check the resolver the browser uses, which may differ from the system resolver due to the influence of Secure DNS configurations or VPN services. Explicit command-line queries target a specific resolver address and provide a more controlled snapshot.
—
## Why the Algorithm Stays the Same
Both KSK-2017 and KSK-2024 use the RSA algorithm with SHA-256. The rollover replaces the key pair while keeping the underlying signature method unchanged. This is intentional.
Eight years ago, when the first root KSK rollover was prepared, there was discussion about using the opportunity to transition to a new algorithm. That transition has not yet happened. The root zone continues to use RSA. Keeping the algorithm the same during a key rollover allows operators to focus on the logistics of trust-anchor distribution without introducing the additional complexity of a cryptographic algorithm change at the same time.
The value of a regular rollover lies in exercising the full lifecycle: distributing new trust anchors, updating resolvers worldwide, verifying acceptance, and retiring old keys. As the first rollover demonstrated, failures can occur at any of these stages even when the cryptography itself is sound.
The Internet Assigned Numbers Authority (IANA) has targeted an idealized three-year interval between rollovers, balancing the benefits of regular practice against the operational effort and risk involved. The gap between the two rollovers so far has been longer than planned, partly due to pandemic-related disruptions and partly due to time needed for upgrading the hardware that protects the root’s private signing keys.
—
## What Comes After October 2026
The October 11 switch marks the moment when KSK-2024 becomes the active signer of the root’s DNSKEY set. However, the rollover process continues well beyond that date. ICANN plans to revoke KSK-2017, remove it from the root zone, and eventually delete its private key. It is important to understand that stopping a key from signing and removing trust in that key are separate actions, each requiring its own timeline.
Looking further ahead, ICANN has proposed a future root algorithm rollover to **ECDSA P-256**. This elliptic-curve algorithm produces significantly smaller keys and signatures compared to the RSA algorithm currently in use, offering efficiency benefits. This proposal is distinct from the October 2026 key replacement and does not involve post-quantum cryptography.
Meanwhile, some public resolvers have already begun supporting **ML-DSA-44** (formerly known as Dilithium), a post-quantum signature scheme designed to resist attacks from future quantum computers. For DNSSEC’s entire chain of trust to become post-quantum secure, every level — signed domains, their parent zones, and the root — must adopt post-quantum cryptographic methods. Introducing a post-quantum KSK at the root will require yet another root key rollover.
The rollovers being performed now serve as rehearsals for that future transition. They allow operators to test trust-anchor distribution, confirm that resolvers have accepted new keys, and retire old ones. The sentinel mechanism developed under RFC 8509 will play a critical role in verifying that resolvers completed these updates successfully.
—
## FAQ
### What is a DNSSEC trust anchor?
A trust anchor is a public key or its fingerprint that a DNS resolver has been configured to trust. It serves as the starting point for DNSSEC validation, allowing the resolver to verify the authenticity of DNS responses without needing a parent zone to vouch for it.
### Why does the root KSK rollover matter if most websites are unaffected?
The root is the top of the DNS hierarchy. If a resolver loses trust in the root’s signing key, it cannot validate DNSSEC signatures for any domain in the root zone. This means websites across all top-level domains could become unreachable, even though those sites themselves are functioning normally.
### Do I need to take action if I use a major public DNS service?
If you rely on major public DNS resolvers such as 1.1.1.1 or similar services, no action is required on your part. These providers have already updated their systems to trust the new key. However, you can still run a readiness test to confirm that the resolver path you use has accepted the new key.
### What if my resolver does not support the sentinel protocol?
If your resolver does not support RFC 8509 sentinel queries, the test result will be inconclusive. An inconclusive result does not necessarily mean the new key is missing — it means the resolver cannot be queried in this way. In that case, you should consult your resolver’s documentation or contact your software vendor to confirm support for trust-anchor updates.
### Is this rollover changing the cryptographic algorithm?
No. Both the old and new keys use RSA with SHA-256. The rollover replaces the key pair while keeping the signature algorithm the same. A separate proposal for an algorithm change to ECDSA P-256 is under consideration for a future date.
### How can I check if my resolver trusts the new key?
You can visit a readiness test website that uses the sentinel protocol to query your resolver. You can also run `dig` commands directly against a known resolver to check sentinel responses manually. Results showing a valid response for the “is trusted” sentinel and `SERVFAIL` for the “is not trusted” sentinel indicate that the resolver accepts the new key.
### What happens to the old key after October 2026?
The old key will continue to exist in the root zone for a period after the rollover. ICANN plans to eventually revoke it, remove it from the root zone, and delete its private key. The exact timeline for these steps will be managed separately from the October 2026 signing change.
### Could a VPN or Secure DNS affect the test results?
Yes. If you use a VPN or a browser with Secure DNS enabled, the resolver your browser queries may differ from your system’s default resolver. Browser-based tests reflect the resolver path your browser uses, while command-line `dig` queries can be directed at a specific resolver address for a more precise check.
—
## Conclusion
The upcoming DNS root KSK rollover on October 11, 2026 represents a significant milestone in the ongoing maintenance of the internet’s foundational infrastructure. By replacing the root’s signing key, operators ensure that cryptographic trust remains fresh and resilient, while also building the operational experience needed for future transitions — including potential algorithm changes and the eventual adoption of post-quantum cryptography.
Most users will not notice any disruption, provided their DNS resolvers have been properly updated. The key steps for operators are to confirm that their validating resolvers trust KSK-2024 (key tag 38696), to follow vendor guidance for updating trust anchors if needed, and to use available testing tools to verify readiness. The sentinel protocol introduced in RFC 8509 gives everyone — from infrastructure engineers to curious users — a practical way to verify that their resolver is prepared.
Preparation is straightforward, but it is time-sensitive. With the rollover date approaching, there is no better moment to confirm that your DNS resolution path is ready.
Thank you for reading
