A scheduled change to the DNS root's cryptographic signing key is coming on October 11, 2026. This key-signing key (KSK) rollover—only the second in the root's history—will swap KSK-2017 for KSK-2024 as the signer of the root's DNSKEY record set. The KSK anchors DNSSEC's chain of trust, allowing DNS resolvers to verify that answers are authentic through cryptographic signatures. Validating resolvers must already trust the replacement key before the switch occurs, or websites could become unreachable for their users.

Experience from the first root KSK rollover in 2018 revealed a practical problem: resolvers sometimes lost their learned trust in new keys during software upgrades or when moving between machines. Publishing the key in advance solved only part of the challenge. There was no straightforward way for users to verify whether their resolvers had actually retained the new key.

Most website operators need not take action for this rollover. Those running DNSSEC-validating resolvers should verify that their systems trust KSK-2024 (key tag 38696) and follow their software vendor's update instructions if the key is absent. Cloudflare customers using the company's DNS service, or relying on 1.1.1.1 and Gateway DNS, require no changes—those systems already trust KSK-2024.

Cloudflare has deployed a readiness test at its website that checks whether the resolver used by your browser trusts the new key. The test implements RFC 8509, a standard for root key trust anchor sentinels that Cloudflare has built into 1.1.1.1 ahead of the rollover.

How DNSSEC trust is anchored

A DNS resolver translates domain names into IP addresses for devices. DNSSEC allows the resolver to verify digital signatures on DNS records, confirming they are genuine and unaltered. To trust those signatures, the resolver must also verify that the public keys belong to the correct domains.

For a domain like cloudflare.com, trust flows through a chain from the DNS root to the .com registry to cloudflare.com itself. Each parent publishes a Delegation Signer (DS) record containing a fingerprint of its child's public key, allowing the resolver to authenticate that child's signing key.

The root zone presents a unique problem: it has no parent to confirm its keys. Instead, a validating resolver begins with a root public key—or its fingerprint—that it already trusts. This is called a trust anchor.

The root maintains two distinct signing keys. The zone-signing key (ZSK) signs the root's DNS records, including DS records for top-level domains. The key-signing key (KSK) signs the DNSKEY record set, which lists all public keys published by the root. A resolver uses its trusted KSK to verify that list, then uses the ZSK from the list to verify the root's other records.

The consequences of failed DNSSEC validation can be severe. Websites may function normally but become unreachable to users whose resolvers reject the cryptographic signatures. A root KSK rollover changes the starting point of those validation checks. If a resolver does not trust the replacement key, its users could lose access to any website under any top-level domain.

KSK-2024 (key tag 38696) will replace KSK-2017 (key tag 20326) as the signer of the root's DNSKEY set. Validating resolvers must trust the new key before that switch.

Automatic key distribution and the lessons of 2018

RFC 5011 enables resolvers to learn new root trust anchors automatically. The root publishes the new KSK alongside the existing one in its DNSKEY set. Because the existing KSK continues signing that set, a resolver can use its current trusted key to verify records containing the replacement.

Before accepting a new key as a trust anchor, the resolver must wait at least 30 days while repeatedly checking that the new key remains in the signed DNSKEY records. After the waiting period, the resolver must successfully verify the records containing the new key once more before accepting it.

KSK-2024 has appeared in the root's DNSKEY set since January 11, 2025, giving resolvers with automatic trust-anchor updates time to discover and accept it before the October 11, 2026 signing change. Each resolver's waiting period begins when it first sees and verifies the new key.

Cloudflare took a different approach with 1.1.1.1. The company added KSK-2024 directly to the resolver's built-in trust anchors in July 2024, alongside KSK-2017. A resolver running updated software therefore has the new anchor available from startup. This decision reflected lessons from 2018, when software upgrades and machine migrations caused some resolvers to lose their automatically learned trust-anchor state. By including KSK-2024 in the software by default, Cloudflare avoided depending on each resolver retaining a key it had learned on its own.

Despite adding KSK-2024 to its resolver's built-in trust anchors in July 2024, users of 1.1.1.1 and Gateway DNS had no straightforward way to verify whether the resolver answering their queries actually trusted the new key.

Testing resolver readiness with trust anchor sentinels

RFC 8509 defines the root key trust anchor sentinel, a protocol for asking a supporting resolver whether it trusts a particular root key. The mechanism uses ordinary DNS queries directed at specially named domains.

Cloudflare's readiness test uses this protocol to check for KSK-2024. Two domain names pose opposite questions: is-ta-38696 asks whether the key is trusted, while not-ta-38696 asks whether it is not trusted.

Both names carry valid DNSSEC-signed address records. A resolver supporting the sentinel first validates those records, then either returns the response directly or replaces the answer with SERVFAIL, depending on whether it trusts the key.

For a validating resolver with sentinel support, SERVFAIL for not-ta-38696 is expected when KSK-2024 is trusted. The resolver deliberately rejects the "not trusted" query.

Sentinel labels such as root-key-sentinel-is-ta-38696 can be used under any DNSSEC-signed domain. Cloudflare uses dnstest.dev for its tests. You can run the two queries directly against 1.1.1.1:

$ dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer

;  DiG 9.10.6  @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADERHEADER

The website also checks that an ordinary signed name resolves, that a deliberately invalid DNSSEC name is rejected, and that the resolver responds to a sentinel query for the current root key. These controls help distinguish a meaningful result from a failed lookup or unsupported protocol. If sentinel support cannot be established, the result is inconclusive; it does not mean the new key is missing.

The browser test checks the resolver your browser uses, which may be affected by Secure DNS or a VPN. The dig commands above explicitly query 1.1.1.1. Both provide a snapshot of the resolver path answering those requests.

Same algorithm, different key

Both KSK-2017 and KSK-2024 use RSA/SHA-256. The rollover replaces the key pair while keeping the same method for creating and verifying signatures.

In 2018, Cloudflare noted that a successful rollover would open the door to discussing an algorithm change. Eight years later, the root still uses RSA.

Replacing the key remains valuable. It limits how long a single private key stays in use and exercises the process of distributing new trust anchors, updating resolvers, and retiring old keys. The first rollover demonstrated that those steps can fail even when the cryptography itself works correctly.

The Internet Assigned Numbers Authority (IANA) envisions an idealized three-year rollover interval, balancing regular practice against the work and risk of changing the root key too frequently. The gap since 2018 has been longer. The Internet Corporation for Assigned Names and Numbers (ICANN) attributes the delay to pandemic disruption and upgrades to the hardware that protects the private signing keys.

Changing algorithms would require resolvers to obtain both a new trust anchor and software capable of verifying the new signatures. Regular key rollovers let operators test the trust-anchor updates while keeping the algorithm the same.

Beyond October 2026

The October 11 switch changes which KSK signs the root's DNSKEY set. The rollover continues into 2027, when ICANN plans to revoke KSK-2017, remove it from the root zone, and delete its private key. Stopping a key from signing and removing trust in that key are separate steps.

ICANN has also proposed a future root algorithm rollover to ECDSA P-256. ECDSA produces smaller keys and signatures than the RSA algorithm used today. That proposal is separate from this October's key replacement, and ECDSA is not a post-quantum algorithm.

1.1.1.1 now validates ML-DSA-44 signatures, which are designed to remain secure against attacks using quantum computers. For DNSSEC's whole chain of trust to become post-quantum secure, signed domains, their parent zones, and the root must adopt post-quantum cryptography too. At the root, that means introducing a post-quantum KSK and getting resolvers to trust it.

That will require another root key rollover. The rollovers performed now let operators test how they distribute replacement trust anchors, check that resolvers have accepted them, and retire the old keys. This October's rollover keeps RSA, but exercises the trust-anchor updates needed when the root moves to post-quantum cryptography. The sentinel gives a way to check whether resolvers followed those updates.

Cloudflare encourages DNS providers and resolver developers to support RFC 8509 trust anchor sentinels. If your resolver does not support them, ask your provider or software vendor to add support. Users should be able to check whether their resolver trusts the next root key before a rollover.

The next deadline is October 11. You can check your resolver's readiness at https://dnstest.dev/ksk-2024. If you operate a DNSSEC-validating resolver, confirm that it trusts KSK-2024 (key tag 38696), and follow ICANN's guidance and your software vendor's instructions if the key is missing.