The keys to the Internet change on October 11. Are you ready?: The keys to the Internet change on October 11. Are you ready? On October 11, 2026, the DNS root switches to a new key-signing key (KSK-2024). Learn what this means for you, and how RFC 8509 trust anchor sentinels allow you to test whether your DNS resolver is ready for the rollover.

2026-10-10T06:59:47Z

We also needed to know whether resolvers had retained it, and we couldn’t give users a practical way to check.

The keys to the Internet change on October 11. Are you ready? On October 11, 2026, the DNS root switches to a new key-signing key (KSK-2024). Learn what this means for you, and how RFC 8509 trust anchor sentinels allow you to test whether your DNS resolver is ready for the rollover.: Research context

1: 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. The zone-signing key (ZSK) signs the root’s DNS records, including the DS records for top-level domains such as . The root publishes the new KSK alongside the existing one in its DNSKEY set. That gave resolvers with automatic trust-anchor updates time to discover and accept it ahead of the scheduled October 11, 2026 signing change. This October’s rollover keeps RSA, but exercises the trust-anchor updates we will need when the root moves to post-quantum cryptography. 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. Here we’ll explain how you can configure fully post-quantum secure mutually authenticated TLS connections to your origin server, dive into the engineering details of how we built it, make a shameful confession, and finally explain how this work fits into our overall post-quantum migration roadmap. The per-zone and per-hostname configuration levels now allow customers to upload ML-DSA certificates and private keys (in the FIPS 204 seed format), so that Cloudflare’s TLS client will present this certificate to authenticate itself when connecting to the origin server. Set your SSL/TLS mode to Full (strict) Custom Origin Trust Store is only active when your zone is using Full (strict) mode. Configure your origin server (on NGINX) If you are using COTS (your origin presents the ML-DSA server certificate): server { listen 443 ssl; ssl_certificate /etc/ssl/origin-server. 3; } If you are using AOP (your origin verifies Cloudflare's client certificate): server { listen 443 ssl; ssl_client_certificate /etc/ssl/aop-ca. Verify the post-quantum handshake The TLS handshake between Cloudflare and your origin happens behind the scenes, so you cannot observe it directly by connecting to your proxied hostname from the outside. 27 (expected August 2026) will include native ML-DSA support, and will allow us to drop the CIRCL dependency. We quickly rolled back the change and after a patch to retain support for RSA certificates with technically invalid KeyUsage, fully post-quantum secure TLS to origins is now live and ready to use. Cloudflare's Authenticated Origin Pulls and Custom Origin Trust Store now support post-quantum authentication. We have reached the first of those milestones: our Authenticated Origin Pulls and Custom Origin Trust Store products now support post-quantum (PQ) authentication via Module-Lattice-Based Digital Signature Algorithm (ML-DSA) signatures to protect connections between Cloudflare and customer origin servers. All this to say, the unique requirements of the Cloudflare-to-origin connection have allowed us to deploy post-quantum authentication via ML-DSA authentication ahead of support landing in the WebPKI for the public Internet. Configuring fully PQ-secure origin connections We have added ML-DSA support (for all FIPS 204 parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87) to the Custom Origin Trust Store and Authenticated Origin Pulls products. Custom Origin Trust Store When Cloudflare makes a connection to a customer origin server configured with Full (strict) SSL mode, we authenticate the origin certificate against a default trust store consisting of all commonly trusted Certificate Authorities (CAs) as well as Cloudflare’s origin CA. The Custom Origin Trust Store (COTS) product (which requires Advanced Certificate Manager to be enabled) allows customers to replace this default trust store with a set of CAs they control. COTS now allows customers to upload ML-DSA CAs, such that Cloudflare will trust any origin server certificate chaining to that CA when connecting to the origin. The private key must be generated in the FIPS 204 seed-only encoding, which is the only format Cloudflare currently accepts on upload. Upload the origin CA to Custom Origin Trust Store CA_CERT=$(jq -Rs . com/client/v4/zones/$ZONE_ID/acm/custom_trust_store" \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \ --header "Content-Type: application/json" \ --json "{"certificate": $CA_CERT}" Uploading a COTS CA replaces the default publicly-trusted CAs for the zone. If you prefer per-hostname AOP, use the /origin_tls_client_auth/hostnames/certificates endpoint instead. key) # Upload the ML-DSA client certificate curl "https://api. com/client/v4/zones/$ZONE_ID/origin_tls_client_auth" \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \ --header "Content-Type: application/json" \ --json "{"certificate": $CERT, "private_key": $KEY}" # Enable zone-level Authenticated Origin Pulls curl -X PUT "https://api. If you are using AOP without COTS, Full or higher is sufficient. crt; ssl_verify_client on; } If you are using both together (recommended for full post-quantum mutual TLS): server { listen 443 ssl; ssl_certificate /etc/ssl/origin-server. Verify COTS (origin presents an ML-DSA certificate): If your origin IP is directly reachable (for example, during testing before enabling the Cloudflare proxy), connect to the origin IP directly and validate the certificate: openssl s_client -connect <ORIGIN_IP>:443 \ -servername origin. If your origin is firewalled to only accept Cloudflare IPs, check your origin server's TLS logs or use a packet capture tool such as ssldump or tcpdump on the origin to confirm that Cloudflare negotiated TLS 1. Verify the full Cloudflare-to-origin path: Because the mTLS handshake happens server-to-server, the most reliable way to confirm that Cloudflare is presenting the ML-DSA client certificate is to inspect your origin server logs. For example, in NGINX you can log the client certificate serial number or subject: log_format pq_verify '$remote_addr - $ssl_client_serial $ssl_client_s_dn'; access_log /var/log/nginx/pq-verify. The post-quantum key agreement will be visible in origin server logs or packet captures as the negotiated group. This was a relatively simple change, but repeating this for every service that needs post-quantum authentication support would be a major chore. That

Key findings

has worked well, but when post-quantum authentication support landed in BoringSSL in April 2026, we decided that this update was worth the inconvenience. 27 (August 2026) will come with native ML-DSA support, allowing Go-based services to add post-quantum authentication with a simple version update. Learn what this means for you, and how RFC 8509 trust anchor sentinels allow you to test whether your DNS resolver is ready for the rollover. On October 11, 2026, the DNS root switches to a new key-signing key (KSK-2024). If you run a DNSSEC-validating resolver, check that it trusts the new root key, KSK-2024, and follow your software vendor’s instructions to update its trust anchors if the key is missing. On October 11, 2026, the DNS root is scheduled to change its key-signing key (KSK) for only the second time ever. This time, ask the resolver RFC 8509 defines the root key trust anchor sentinel, a way to ask a supporting resolver whether it trusts a particular root key. The test uses RFC 8509: A Root Key Trust Anchor Sentinel for DNSSEC, which we’ve implemented in 1. How resolvers get the new root key RFC 5011 lets resolvers learn a new root trust anchor automatically. We encourage DNS providers and resolver developers to support RFC 8509 trust anchor sentinels. Before accepting the new key as a trust anchor, the resolver waits at least 30 days and keeps checking the root’s signed DNSKEY records. 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. The key-signing key (KSK) signs the list of public keys published by the root, called the DNSKEY record set. For the root, trust comes from the resolver’s trust anchor rather than a DS record in a parent zone. The new key is KSK-2024, identified by key tag 38696. For our resolver, we added KSK-2024 directly to the software’s built-in trust anchors in July 2024, alongside KSK-2017. Even though we added KSK-2024 to our resolver’s built-in trust anchors in July 2024, users of 1. New key, same algorithm KSK-2017 and KSK-2024 both use RSA/SHA-256. For a validating resolver with sentinel support, the expected results are: Query KSK-2024 is trusted KSK-2024 is not trusted is-ta-38696 Returns a valid response Returns SERVFAIL not-ta-38696 Returns SERVFAIL Returns a valid response For a validating resolver with sentinel support, SERVFAIL for not-ta-38696 is expected when KSK-2024 is trusted. For this rollover, KSK-2024 has been published in the root’s DNSKEY set since January 11, 2025. What comes after October The October 11 switch changes which KSK signs the root’s DNSKEY set. It will replace KSK-2017, key tag 20326, as the signer of the root’s DNSKEY set. Changing algorithms means resolvers need both a new trust anchor and software that can verify the new signatures. When we wrote about the first root KSK rollover in 2018, we had seen resolvers lose their learned trust in the new key during software upgrades or moves between machines. Validating resolvers need to trust the new key before the switch, as otherwise healthy websites could become unreachable. The root KSK rollover changes the starting point of those checks. Validating resolvers need to trust the new key before that switch. As described in our 2018 post, software upgrades and moves between machines caused some resolvers to lose their learned trust-anchor state. In our 2018 post, we wrote that a successful rollover would open the door to discussing an algorithm change. The new key must remain in the records it checks during that period. The existing KSK continues signing that set, so a resolver can use the key it already trusts to verify the records containing the replacement. After the wait, the resolver must successfully verify the records containing the new key again before accepting it. Each resolver’s waiting period starts when it first sees and verifies the new key. We also needed to know whether resolvers had retained it, and we couldn’t give users a practical way to check. The sentinel gives us a way to check whether resolvers followed those updates. 1 and Gateway DNS had no direct way to check whether the resolver answering their queries trusted the new key. Users should be able to check whether their resolver trusts the next root key before a rollover. That will require another root key rollover. Instead, a resolver checking DNSSEC starts with a root public key, or its fingerprint, that it already trusts. You should see the serial number of the aop-client. Sentinel labels such as root-key-sentinel-is-ta-38696 can be used under any DNSSEC-signed domain. com" \ -addext basicConstraints=CA:FALSE \ -addext keyUsage=digitalSignature \ -addext subjectAltName=DNS:origin. csr \ -subj "/CN=cloudflare-aop-client" \ -addext basicConstraints=CA:FALSE \ -addext keyUsage=digitalSignature \ -addext subjectAltName=DNS:cloudflare-aop-client openssl x509 -req -in aop-client. key -CAcreateserial \ -out origin-server. key -CAcreateserial \ -out aop-client. key openssl req -new -x509 -key origin-ca. key openssl req -new -key origin-server. key openssl req -new -x509 -key aop-ca. key openssl req -new -key aop-client. The change is called a KSK rollover. com, allowing the resolver to check that domain’s key. The resolver uses its trusted KSK to verify that list, then uses the ZSK from the list to verify the root’s other records. At the root, that means introducing a post-quantum KSK and getting resolvers to trust it. A resolver running the updated software

Operational implications

therefore has the new anchor available from startup. We fixed that by updating the software to include the new anchor by default. The rollover continues into 2027, when ICANN plans to revoke KSK-2017, remove it from the root zone, and delete its private key. Our readiness test website uses this protocol to check for KSK-2024. To check ahead of time, visit our rollover readiness test. 1 ahead of the rollover. If a resolver does not trust the replacement key, its users may be unable to reach websites under any top-level domain. This is called a trust anchor. 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. 1 and Gateway DNS, you do not need to take any action — our systems already trust KSK-2024. Including KSK-2024 in the software likewise avoids depending on each resolver retaining a key it learned automatically. The root’s signing keys have two different jobs. A resolver that supports 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. You can check your resolver’s readiness at https://dnstest. This key anchors DNSSEC’s chain of trust, which lets DNS resolvers authenticate answers using cryptographic signatures. These key rollovers are the periodic replacement of the cryptographic keys used to sign a zone's DNS records; they are a routine but crucial piece of maintenance, as resolvers that validate DNSSEC will only trust answers whose signatures match the current published keys. DNSSEC lets it check digital signatures on DNS records to verify that they are authentic and have not been changed. The root, however, has no parent to confirm which keys belong to it. com, this follows a chain of trust from the DNS root to . Building on the open, agent-ready web? Agent Readiness is where you find out whether you're one of them, and what to do if you're not yet. Open the Agent Readiness tab in your Cloudflare dashboard and tell us what you're building on the Cloudflare Developer Discord. To help site owners answer these questions, we have integrated our previous work on Agent Readiness into the Cloudflare dashboard, and added our new Answer Engine Optimization (AEO) tool as well. But with Agent Readiness and AEO, you can get the data you need to act. AEO: are AI assistants recommending you? ) So how do you turn this on? Generate certificates You will need OpenSSL 3. The resolver deliberately rejects the “not trusted” query. By observing how models answer these realistic queries, you get metrics such as: Citation Rate: the share of answers in your category that cite your site as a source Prominence: when you are cited, how much of the answer is actually yours and how early it lands Mention Rate: how often assistants name your brand in their answer — for example, how often "Cloudflare" shows up in the response, whether or not cloudflare. We evaluate not just whether your site was mentioned, but whether you were cited as a source, how early your citations appear in the answer, and how much of the final answer's substance is attributed to you. These tools treat agents as a core user base for your site, showing you how an agent will see it, and how often you get recommended. Ready to find out if AI agents are sending customers your way? Diagnostics: is your site ready for agents? Diagnostics tells you whether agents can read your site. Now it means being found, read, and confidently recommended by the agents that guide your customers. Head over to the Overview tab in your dashboard to get your site Agent Ready and request early access to AEO Visibility. You can't look this up like a search ranking. The AEO tab tells you what happens next: when a customer asks an AI assistant a question in your category, does it recommend you or a competitor? Your next customer may not find you through a search engine. And with a pre-existing trust relationship between Cloudflare and customers (i. If you use Cloudflare for your domain's DNS or rely on 1. Each parent publishes a Delegation Signer (DS) record containing a fingerprint of its child’s public key. Most website operators do not need to make any changes for this rollover. Helping you see who's reaching your site and decide how to engage on your own terms is what we've always done. Share of Voice: your slice of citations against those for your competitors, so you can see who is winning the prompts you're losing To evaluate how an AI model perceives your market presence, we build a benchmark across each industry and category before scoring a specific site. Stopping a key from signing and removing trust in that key are separate steps. The rollover replaces the key pair while keeping the same method for creating and verifying signatures. Where DNSSEC trust begins A DNS resolver looks up the addresses of websites and other services for your device. That proposal is separate from this October’s key replacement, and ECDSA is not a post-quantum algorithm. ICANN has also proposed a future root algorithm rollover to ECDSA P-256. If your resolver does not support them, ask your provider or software vendor to add support.

27 (August 2026) will come with native ML-DSA support, allowing Go-based services to add post-quantum authentication with a simple version update.

Read the original sources cited in the article for the full material.

Frequently asked questions

What does the collected research say about The keys to the Internet change on October 11. Are you ready? On October 11, 2026, the DNS root switches to a new key-signing key (KSK-2024). Learn what this means for you, and how RFC 8509 trust anchor sentinels allow you to test whether your DNS resolver is ready for the rollover.?

On October 11, 2026, the DNS root switches to a new key-signing key (KSK-2024).

What are the key details from Cloudflare Blog?

Like most infrastructure, the Internet's fragility is easy to overlook — as long as it's working.