DNS root key-signing key to roll over on October 11, 2026, only the second such change

The DNS root is set to perform a key-signing key rollover on October 11, 2026, an event that has occurred only once before.¹ This operation, known as a KSK rollover, replaces the cryptographic key that serves as the foundation of DNSSEC's chain of trust.¹ The key-signing key allows validating resolvers to verify the authenticity of DNS answers through cryptographic signatures.¹ The first such rollover took place in 2018, making the upcoming change the second in the root's history.¹

The incoming key is designated KSK-2024 and carries key tag 38696.¹ It will take the place of the current root signer, KSK-2017, which is identified by key tag 20326.¹ At the root level, two types of keys are used: the zone-signing key signs DNS records, while the key-signing key signs the DNSKEY record set that contains the public keys.¹ This division of labor means the key-signing key does not sign individual records but instead validates the set of keys used for signing.¹

The root's DNSKEY record set has included KSK-2024 since January 11, 2025.¹ This early publication gives resolvers that rely on automatic updates under RFC 5011 a long period to observe and trust the new key before the changeover.¹ RFC 5011 defines a specification that enables DNS resolvers to discover and trust a new root anchor automatically.¹ Under that process, a resolver must observe a new key continuously in the signed DNSKEY records for at least 30 days before trusting it.¹ Because KSK-2024 has been in the DNSKEY record set since January 2025, resolvers following RFC 5011 have had well over the required 30 days to establish trust.¹

Cloudflare incorporated KSK-2024 directly into its software's default trust anchors in July 2024.¹ As a result, resolvers running Cloudflare's 1.1.1.1 and Gateway DNS already possess trust in the incoming KSK-2024 key.¹ This means users of those services do not need to take any action for the rollover, as their resolvers are pre-configured to trust the new key.¹

For operators of other validating resolvers, RFC 8509 provides a sentinel protocol that allows users to test whether a DNS resolver trusts an identified root key.¹ Under the sentinel testing mechanism, querying is-ta-38696 evaluates if key 38696 is trusted, whereas querying not-ta-38696 evaluates if it is untrusted.¹ A sentinel-compliant validating resolver that trusts KSK-2024 is designed to respond with a SERVFAIL error when queried for not-ta-38696.¹ This test can help administrators confirm that their resolvers have correctly adopted the new key before the rollover date.¹

The key-signing key is the anchor for DNSSEC's chain of trust, enabling validating resolvers to confirm the authenticity of answers using cryptographic signatures.¹ Without a trusted key-signing key, DNSSEC validation cannot succeed, and resolvers may treat responses as insecure or bogus.¹ The rollover therefore affects the entire DNS ecosystem, from root server operators to end-user resolvers.¹

The process of updating the root key-signing key is known as a KSK rollover.¹ The first such rollover occurred in 2018, and the upcoming one in 2026 will be the second.¹ The long gap between rollovers reflects the critical nature of the key and the need for careful coordination.¹

The root's DNSKEY record set has contained KSK-2024 since January 11, 2025, giving resolvers that follow RFC 5011 ample time to observe and trust it.¹ RFC 5011 requires a resolver to see a new key continuously for at least 30 days before trusting it.¹ Because the key has been published for well over a year, the 30-day requirement is easily met for resolvers that have been online and updating.¹

Cloudflare's early adoption of KSK-2024 in July 2024 means its 1.1.1.1 and Gateway DNS resolvers already trust the new key.¹ This pre-emptive action ensures that users of those services will not experience validation failures when the rollover occurs.¹ Other resolver operators can use the RFC 8509 sentinel tests to verify their own readiness.¹

The sentinel protocol defined in RFC 8509 allows users to test whether a DNS resolver trusts an identified root key.¹ Querying is-ta-38696 checks if key 38696 is trusted, while querying not-ta-38696 checks if it is untrusted.¹ A sentinel-compliant validating resolver that trusts KSK-2024 should return a SERVFAIL error for not-ta-38696.¹ These tests provide a practical way for administrators to confirm that their resolvers have adopted the new key.¹

The upcoming rollover is a significant event because the root key-signing key is the ultimate trust anchor for DNSSEC.¹ Only one previous rollover has occurred, in 2018, so the 2026 change is only the second in the root's history.¹ The new key, KSK-2024, with key tag 38696, will replace KSK-2017, with key tag 20326.¹ Resolvers that have not yet adopted the new key may face validation issues after the rollover, but tools like the sentinel tests can help identify such cases.¹