DNS root key rollover requires trust in KSK-2024
DNS, the Domain Name System that translates website names into network addresses, faces an important trust update on October 11, 2026: the root will switch to a replacement signing key. In their October 6 report, Cloudflare’s Sebastiaan Neuteboom and James Godlewski urge operators to confirm that their DNS checking systems trust KSK-2024, key tag 38696. The change retains the existing cryptographic algorithm, but accepting the replacement key is essential to keeping name lookups working correctly.
The affected systems are DNSSEC-validating resolvers. A resolver looks up names on behalf of users and applications; DNS Security Extensions (DNSSEC) let it check digital signatures to establish that DNS information is authentic. That verification depends on a chain of trust reaching the root, the top of the DNS hierarchy. A root key-signing key (KSK) signs the root’s DNSKEY set, the published collection of its DNS verification keys. A trust anchor is the key information a resolver accepts as its starting point for those checks. Without the appropriate trusted key, verification can fail even when the requested service itself is healthy.
The October 11 switch changes which KSK signs that root key collection. It does not complete the retirement of the previous key. According to the report, the Internet Corporation for Assigned Names and Numbers (ICANN) plans to revoke KSK-2017 in 2027, remove it from the root zone, the DNS records at the top of the hierarchy, and delete its private key. A private key is the secret material used to create signatures. Ending a key’s signing role and withdrawing trust in it are separate operations, which is why the transition extends beyond October.
For users, the report points to the resolver readiness test. It uses a trust anchor sentinel, a special DNS query that can reveal whether a resolver has accepted a particular root key. The test also checks that a normally signed name resolves successfully, that a name with deliberately invalid DNSSEC information is rejected, and that the resolver answers a sentinel query concerning the current root key. These controls help separate a meaningful readiness result from a lookup failure or a resolver that does not support the testing mechanism.
An important limit is that an inconclusive test does not establish that the new key is missing. If sentinel support cannot be confirmed, the test cannot answer that question. It also checks the resolver used by the browser, which may be influenced by Secure DNS, a browser option for encrypted DNS lookups, or a virtual private network (VPN), which carries traffic through another network connection. Cloudflare contrasts this with its command-line examples using dig, a DNS lookup tool, which explicitly query its 1.1.1.1 resolver. Either method captures only the resolver path answering those particular requests, not every DNS system an organisation might use.
KSK-2017 and KSK-2024 both use RSA/SHA-256, the same combination of cryptographic methods for creating and checking signatures. This is a replacement of the key pair, not a change of algorithm. Cloudflare recalls writing in 2018 that a successful rollover could open discussion of an algorithm change; eight years later, the root still uses RSA. Rotating the key nevertheless limits the time one private key remains in use and rehearses the distribution of replacement trust anchors, resolver updates and old-key retirement. The report notes that the first rollover demonstrated how those operational steps can fail even when the cryptography works correctly.
The Internet Assigned Numbers Authority (IANA) envisages an ideal three-year interval between rollovers, balancing regular operational practice against the effort and risk of frequent changes. The period since 2018 has been longer. ICANN attributes that delay to pandemic disruption and upgrades to the hardware protecting private signing keys. Keeping the algorithm unchanged lets operators test trust-anchor updates on their own. An algorithm transition adds another requirement: resolver software must also be able to verify the new kind of signature.
ICANN has separately proposed a future root algorithm transition to ECDSA P-256, an elliptic-curve digital signature method that produces smaller keys and signatures than RSA. It is not part of October’s key replacement, and it is not post-quantum cryptography, meaning cryptography designed to resist attacks using quantum computers. Cloudflare says 1.1.1.1 now validates ML-DSA-44 signatures, which are designed for that resistance. But support in a resolver alone cannot make the whole DNSSEC chain post-quantum secure: signed domains, their parent zones and the root would all need to adopt suitable cryptography.
At the root, that future transition would require a post-quantum KSK and another rollout to get resolvers to trust it. The present replacement therefore exercises a relevant operational process without delivering quantum resistance itself. Cloudflare encourages DNS providers and resolver developers to implement RFC 8509, the specification for trust anchor sentinels, so users can check readiness before a rollover rather than depend on an untestable assumption.
For readers reviewing who handles their name lookups, AEU DNS offers private, secure DNS, although that service description alone does not establish its readiness for this particular rollover. The immediate task for anyone operating a DNSSEC-validating resolver is more specific: verify that it trusts KSK-2024 with key tag 38696, and, if it does not, follow ICANN’s guidance and the resolver software vendor’s instructions. Users whose test is inconclusive should ask their DNS provider about sentinel support and readiness, rather than interpret uncertainty as either a confirmed failure or a clean bill of health.