Cloudflare spent the second week of September 2026 rewriting two pieces of internet plumbing that most engineers never think about: the TLS handshake between its edge and origin servers, and the DNSSEC signatures that back DNS lookups on its 1.1.1.1 resolver. On September 8, the company rolled out Automatic Key Exchange, a system that pushes post-quantum TLS 1.3 handshakes to origin servers across what it describes as 45 billion daily connections. Two days later, on September 10, it flipped on post-quantum DNSSEC validation using NIST’s ML-DSA-44 signature scheme, becoming one of the first major resolver operators to validate quantum-resistant DNS signatures at scale.
Neither announcement reads like a headline-grabbing product launch. There is no new dashboard, no pricing tier, no press conference. But together they mark a quiet inflection point: the plumbing that secures a meaningful share of the web’s traffic and DNS lookups is being rebuilt around cryptography designed to survive a quantum computer that does not exist yet. Understanding what changed, why the signatures ballooned to 2,420 bytes, and what NIST’s 2030 deadline means for everyone else is the subject of this analysis.
What Cloudflare Actually Shipped This Month
Cloudflare’s September push breaks into two distinct engineering efforts, the latest entries in the company’s ongoing cloud infrastructure and edge security record. The first, Automatic Key Exchange, targets the connection between Cloudflare’s edge and the origin servers that sit behind it, the leg of the request that customers’ own infrastructure has to negotiate. The second, post-quantum DNSSEC, targets the 1.1.1.1 public resolver that answers DNS queries for millions of users and applications worldwide. Both use hybrid schemes that combine a classical algorithm with a post-quantum one, so a connection stays secure even if one half of the pair is later broken.
The timing is not accidental. Cloudflare has been measuring adoption of post-quantum TLS since March 2024, when hybrid post-quantum key exchange covered roughly 2% of connections reaching its edge, according to Cloudflare’s own reporting cited in shattered.io’s coverage of that adoption curve. By late 2025 that figure had climbed past 50%. The origin-side and DNS-side rollouts this month close two of the remaining gaps: traffic that never made it past the edge in post-quantum form, and DNS lookups that stayed on classical RSA or ECDSA signatures no matter how the TLS session was negotiated.
Automatic Key Exchange: Post-Quantum TLS for 45 Billion Daily Connections
Automatic Key Exchange addresses a problem specific to reverse proxies. Cloudflare sits between a visitor’s browser and a customer’s origin server, terminating the visitor-facing TLS connection and then opening a second TLS connection to the origin on the customer’s behalf. Post-quantum adoption on the visitor-facing leg does nothing to protect that second, origin-facing hop unless the origin server also speaks a post-quantum key exchange method, and until this month, getting that right required manual configuration on the customer’s side.
Automatic Key Exchange removes that manual step. Cloudflare scans origin servers for post-quantum support and negotiates a hybrid X25519+ML-KEM-768 handshake automatically where the origin allows it, falling back to classical key exchange where it does not. Cloudflare says the feature now touches the origin-facing side of roughly 45 billion connections a day, a figure that spans the customer base already covered by the initial rollout rather than the full breadth of every domain on Cloudflare’s network.
Why the Retry Rate Dropped From 52% to 3.7%
The number that matters more than the headline connection count is what happened to handshake retries. Early post-quantum TLS 1.3 handshakes frequently triggered a HelloRetryRequest, an extra round trip that happens when a server cannot process the client’s first guess at a key share and has to ask for a different one. For post-quantum key exchange specifically, that retry has historically been common because ML-KEM key shares are large enough that some servers and middleboxes choke on the first attempt.
Within the set of origins already scanned under Automatic Key Exchange, Cloudflare reports that the retry rate fell from about 52% to roughly 3.7%, and that 99.2% of post-quantum TLS 1.3 connections in that cohort now complete in a single round trip. That is a meaningful latency win: every avoided HelloRetryRequest saves a full network round trip on connection setup, which matters at the scale of billions of daily handshakes. It is also, structurally, a compatibility fix as much as a security one, since the retries were largely a symptom of origin servers and network paths not yet tuned for post-quantum key sizes.
Post-Quantum DNSSEC Arrives on the 1.1.1.1 Resolver
The DNSSEC change is the more unusual of the two, because DNSSEC has resisted post-quantum upgrades longer than TLS. DNSSEC protects DNS answers with digital signatures so a resolver can confirm a response has not been tampered with in transit. Every signature algorithm DNSSEC has used at scale up to now, RSA and ECDSA included, is breakable by a sufficiently capable quantum computer running Shor’s algorithm, which is precisely the failure mode post-quantum cryptography exists to close.
On September 10, Cloudflare’s 1.1.1.1 resolver began validating DNSSEC signatures generated with ML-DSA-44, the smallest parameter set in NIST’s Module-Lattice-Based Digital Signature Algorithm family, standardized as FIPS 204. Cloudflare detailed the rollout in a post on its engineering blog, describing 1.1.1.1 as one of the first large public resolvers to validate post-quantum DNSSEC signatures in production rather than in a lab environment.
Inside ML-DSA-44: Why the Signature Is 38 Times Bigger
The tradeoff behind ML-DSA-44 is size. A single ML-DSA-44 signature runs 2,420 bytes, and its public key adds another 1,312 bytes, for a combined 3,732 bytes when a resolver fetches the DNSKEY record set it needs to validate a zone. Compare that to ECDSA P-256, which produces a 64-byte signature, or RSA-2048 with SHA-256, which produces a 256-byte signature backed by a 260-byte public key. ML-DSA-44’s signature alone is close to 38 times larger than ECDSA P-256’s.
That size difference is not cosmetic. DNS was built around UDP, a transport with no guaranteed delivery and a practical payload ceiling that most resolvers cap around 1,400 bytes under standard EDNS settings. A 2,420-byte signature blows past that ceiling before the rest of a DNS response is even counted, which forces truncation and a fallback to TCP, or a shift toward other transports such as DNS-over-HTTPS. Cloudflare’s own writeup acknowledges the collision directly: the signatures are simply too big for the transport DNS was designed around forty years ago.
How ML-DSA-44 Stacks Up Against RSA and ECDSA
The size gap is easiest to read in a straight comparison. The table below lines up the three algorithms now in active use across Cloudflare’s DNSSEC deployment, using the figures Cloudflare and independent post-quantum research sites published alongside the September 10 rollout.
| Algorithm | Public key size | Signature size | Quantum-resistant |
|---|---|---|---|
| RSA-2048 / SHA-256 | 260 bytes | 256 bytes | No |
| ECDSA P-256 | 64 bytes | 64 bytes | No |
| ML-DSA-44 (FIPS 204) | 1,312 bytes | 2,420 bytes | Yes |
The pattern holds across the post-quantum signature family generally, not just ML-DSA-44. Shattered.io’s earlier comparison of ML-DSA against SLH-DSA found similar size penalties baked into every NIST-approved post-quantum signature scheme, which is why algorithm choice for DNSSEC specifically favors the smallest available parameter set rather than the strongest one.
Why Cloudflare Refused the Classical Fallback
RFC 6840, the DNSSEC protocol implementation notes published by the IETF, technically permits a resolver to fall back to a classical signature algorithm if a post-quantum one cannot be validated cleanly. Cloudflare chose not to build that fallback into 1.1.1.1’s post-quantum DNSSEC validation. If a signed zone offers only classical algorithms, 1.1.1.1 validates them as it always has. But where ML-DSA-44 signatures are present and fail to validate, the resolver does not quietly step down to a classical signature as an escape hatch.
The reasoning tracks a broader principle in post-quantum migrations: a fallback path that is technically standards-compliant can also become the exact downgrade attack an adversary looks for, tricking a resolver into accepting a weaker signature it would otherwise reject. Refusing the classical fallback for post-quantum-signed zones closes that door, at the cost of being less forgiving toward zones that misconfigure their DNSSEC signing during the transition period.
The Harvest-Now-Decrypt-Later Clock Driving the Urgency
None of this matters if a quantum computer capable of breaking RSA-2048 or ECDSA P-256 never arrives. But the threat model that post-quantum cryptography defends against does not require the computer to exist today. It requires an adversary to record encrypted or signed traffic now and decrypt or forge it once a capable quantum computer does exist, a strategy generally called harvest-now-decrypt-later. Data with a long shelf life, health records, government communications, long-lived DNS trust anchors, is the most exposed under that model, because the value of breaking it later has not expired by the time the technology catches up.
DNSSEC sits closer to the harvest-now-decrypt-later risk than most people assume. A forged DNSSEC signature does not just expose a single conversation, it can redirect an entire domain’s traffic to an attacker-controlled server while still passing signature validation. Locking that particular door with a quantum-resistant signature now, years before a capable quantum computer is expected, removes a long-lived target from the harvest queue entirely.
NIST’s 2030 and 2035 Deadlines Set the Enterprise Clock
Cloudflare’s rollout does not exist in a vacuum. NIST’s IR 8547 draft, published in November 2024 and still moving through revision, lays out a two-stage transition timeline for the exact algorithms Cloudflare is now retiring from DNSSEC and hardening in TLS. Under that guidance, public-key algorithms offering roughly 112 bits of security, RSA-2048 and ECDSA P-256 chief among them, are deprecated for new federal systems after 2030 and disallowed entirely after 2035, according to NIST’s published draft.
That timeline is a federal procurement guideline, not a law that binds private companies. But it functions as the de facto migration schedule most large enterprises and cloud vendors plan around, because federal contractors, healthcare systems, and financial institutions with compliance obligations tend to adopt NIST timelines as their own internal deadlines regardless of whether a specific regulation requires it. Nine years feels distant. For an organization that has not yet inventoried where RSA-2048 and ECDSA live across its infrastructure, it is closer than it looks once discovery, testing, and staged rollout are factored in.
Where AWS, Google Cloud, Akamai and Fastly Stand
Cloudflare’s edge position gives it a structural advantage here that is worth being honest about. Because it terminates TLS for a large share of the web’s traffic and operates one of the most widely used public DNS resolvers, Cloudflare can flip a default for millions of domains in a single announcement, something a cloud infrastructure provider serving individual customer deployments cannot do as cleanly.
Major cloud and CDN competitors have not published comparable production rollouts of post-quantum DNSSEC validation or automatic post-quantum origin handshakes at the scale Cloudflare is now describing. AWS, Google Cloud, Akamai, and Fastly have all engaged with post-quantum TLS support in their broader security roadmaps, largely through support for hybrid key exchange in load balancers and CDN edges, but none had announced a public resolver validating post-quantum DNSSEC signatures by the time Cloudflare shipped its September rollout. That gap gives Cloudflare a first-mover claim on the DNS side of post-quantum migration specifically, even as adoption of post-quantum TLS itself has become broadly standard across major browsers and CDNs.
From 2% to Half the Web: Cloudflare’s Post-Quantum Timeline
Cloudflare’s September moves are the latest step in a rollout that has been running for four years. The table below traces the major public milestones, drawn from Cloudflare’s own engineering blog posts across that period.
| Date | Milestone |
|---|---|
| October 2022 | Post-quantum hybrid key agreement enabled by default for all websites and APIs on Cloudflare’s network |
| March 2024 | Roughly 2% of TLS 1.3 connections reaching Cloudflare’s edge use post-quantum key exchange |
| 2024 | First phase of quantum-safe protection extended to Cloudflare’s Zero Trust platform |
| Late 2025 | Post-quantum hybrid key exchange adoption passes roughly 50% of human-generated HTTPS traffic at the edge |
| September 8, 2026 | Automatic Key Exchange ships, extending post-quantum TLS to the origin-facing leg of roughly 45 billion daily connections |
| September 10, 2026 | 1.1.1.1 resolver begins validating post-quantum DNSSEC signatures using ML-DSA-44, without a classical fallback |
The trajectory from 2% to roughly half of edge traffic in under two years, documented in shattered.io’s broader post-quantum cryptography coverage, tracks closely with when Chrome and other major browsers turned on hybrid post-quantum key exchange by default. Browser defaults, not enterprise mandates, did most of the early heavy lifting on the TLS side. DNSSEC has no equivalent browser-level lever, which is part of why its post-quantum transition lagged TLS by roughly four years.
Market Impact: What This Costs and Who Pays For It
The direct cost of Cloudflare’s rollout to its customers is effectively zero at the surface level: both Automatic Key Exchange and post-quantum DNSSEC validation are default behaviors rather than paid add-ons, consistent with how Cloudflare has positioned every prior stage of its post-quantum rollout since 2022. The real cost lands downstream, on the origin servers, DNS providers, and network appliances that now have to handle larger key shares and signatures without falling over.
That downstream cost is not trivial. Larger TLS key shares increase the chance of packet fragmentation on networks with restrictive MTU settings. Larger DNSSEC signatures push more DNS traffic onto TCP, which is slower to establish and more expensive to sustain at scale for resolver operators who are not Cloudflare-sized. Enterprises running their own authoritative DNS infrastructure, rather than delegating to a managed resolver, inherit that cost directly as they plan their own migration to post-quantum DNSSEC signing over the next several years, a process that involves re-signing entire zones and testing resolver compatibility across a customer base whose software stack they do not fully control.
What Cloudflare Has Said, In Its Own Words
Cloudflare has been unusually consistent in how it has framed each stage of this rollout publicly. Announcing the original 2022 default rollout of post-quantum TLS, the company wrote: “Starting today, as a beta service, all websites and APIs served through Cloudflare support post-quantum hybrid key agreement,” adding that the change required no customer action because “this is on by default; no need for an opt-in,” according to Cloudflare’s official announcement.
By its 2024 progress update, Cloudflare reported that “today, nearly two percent of all TLS 1.3 connections established with Cloudflare are secured with post-quantum cryptography,” a baseline documented in its 2024 post-quantum internet report. Extending the same default-on posture into its Zero Trust product line, Cloudflare framed the move as foundational rather than incremental, stating: “Today marks a milestone: We’re launching the first phase of quantum-safe protection for our Zero Trust platform,” per its Zero Trust post-quantum announcement. Cloudflare’s developer documentation independently confirms the underlying default, noting that “as of October 2022, all websites and APIs served through Cloudflare over TLS 1.3 support post-quantum hybrid key agreement,” per its published SSL documentation.
Historical Context: DNSSEC’s Slow, Reluctant Modernization
DNSSEC has a track record of adopting new cryptography slowly. The protocol itself took roughly a decade from its early 2000s design work to meaningful deployment across top-level domains, and its shift from RSA to ECDSA as a smaller, faster signature option took years longer still because zone operators had to re-sign and test compatibility across resolver software that could not always be upgraded in lockstep. Post-quantum DNSSEC is repeating that pattern under compressed time pressure, since the NIST deprecation clock gives the ecosystem roughly nine years rather than the decade-plus DNSSEC itself took to reach broad adoption.
What makes Cloudflare’s move notable against that backdrop is that it is validating post-quantum signatures on the resolver side before most authoritative DNS operators are signing zones with post-quantum algorithms at any scale. That is roughly the reverse order of how ECDSA adoption unfolded, where authoritative signing led and resolver validation caught up. Cloudflare is betting that resolver-side readiness, built now, will not sit idle waiting for zones to catch up.
What Security and Infrastructure Teams Should Do Now
For teams running services behind Cloudflare, both changes this month require no action to benefit from them, matching the company’s consistent default-on approach since 2022. The practical to-do list sits with teams that operate their own origin infrastructure or authoritative DNS outside Cloudflare’s network. Origin operators should confirm their TLS stack supports hybrid X25519+ML-KEM-768 key exchange, since Automatic Key Exchange can only extend post-quantum protection to origins that are capable of negotiating it. DNS operators signing their own zones should begin testing ML-DSA-44 or other NIST-approved post-quantum signature algorithms in a staging environment, specifically checking how their resolver software and any middleboxes on the path handle the larger signature sizes documented above.
Enterprises with compliance obligations tied to NIST’s broader post-quantum cryptography finalization should treat Cloudflare’s rollout, which arrives against the backdrop detailed in Cloudflare’s 2026 threat report, as a preview of the operational friction they will hit during their own migrations: larger payloads, more TCP fallback, and compatibility testing against network equipment that was never designed with 2,420-byte DNS signatures in mind.
Five Predictions for Post-Quantum Edge Security
- Expect at least one of AWS, Google Cloud, Akamai, or Fastly to announce a comparable post-quantum DNSSEC validation feature for a major public resolver within the next 12 months, closing the first-mover gap Cloudflare currently holds.
- Post-quantum TLS adoption at Cloudflare’s edge, running near 50% of human-generated HTTPS traffic in late 2025, is likely to cross a clear majority of measured connections during 2027 as browser defaults and CDN automation continue compounding.
- DNS software vendors will ship updated EDNS buffer size defaults and TCP fallback handling specifically tuned for post-quantum DNSSEC signature sizes, since the current UDP truncation behavior was not designed around 2,420-byte payloads.
- Enterprises with 2030 compliance deadlines under NIST IR 8547 will increasingly treat Cloudflare-style automatic key exchange features as a template for their own vendor requirements, pushing more infrastructure providers toward default-on rather than opt-in post-quantum configurations.
- Expect renewed debate over DNSSEC’s transport assumptions, since post-quantum signature sizes may accelerate a broader industry shift toward DNS-over-HTTPS and DNS-over-TLS as the default transport for signed zones, rather than treating UDP with TCP fallback as sufficient long-term.
Frequently Asked Questions
What is Automatic Key Exchange from Cloudflare?
Automatic Key Exchange is a Cloudflare feature, launched September 8, 2026, that automatically negotiates post-quantum TLS 1.3 handshakes between Cloudflare’s edge and customer origin servers, without requiring manual configuration on the customer’s side.
What is ML-DSA-44 and why does DNSSEC use it?
ML-DSA-44 is the smallest parameter set of NIST’s Module-Lattice-Based Digital Signature Algorithm, standardized as FIPS 204. Cloudflare’s 1.1.1.1 resolver uses it because it offers post-quantum security with a smaller signature than larger ML-DSA parameter sets, though it still produces a 2,420-byte signature, far larger than the 64-byte ECDSA P-256 signatures DNSSEC has traditionally used.
Why are post-quantum DNSSEC signatures so much bigger than classical ones?
Post-quantum signature algorithms rely on different mathematical structures, such as lattice problems, that are believed to resist attacks from quantum computers. Those structures require significantly more data per signature than classical elliptic curve or RSA algorithms. ML-DSA-44’s 2,420-byte signature is roughly 38 times larger than an ECDSA P-256 signature.
Does this affect regular internet users?
Most users will not notice any difference. Cloudflare has enabled both features by default with no action required from website visitors, following the same default-on approach it has used for post-quantum TLS since October 2022.
What is the NIST 2030 deadline for RSA and ECDSA?
Under NIST IR 8547, published as an initial public draft in November 2024, public-key algorithms offering roughly 112 bits of security, including RSA-2048 and ECDSA P-256, are set to be deprecated for new federal systems after 2030 and disallowed entirely after 2035.
What is harvest-now-decrypt-later and why does it matter for DNS?
Harvest-now-decrypt-later describes an attack strategy where an adversary records encrypted or signed data today and waits for future quantum computing advances to break it. For DNS, a forged DNSSEC signature can redirect an entire domain’s traffic to a malicious server, which is why securing DNS trust anchors against future quantum attacks now is treated as high priority.
Have other major cloud providers rolled out post-quantum DNSSEC?
As of Cloudflare’s September 2026 rollout, no major competing cloud or CDN provider, including AWS, Google Cloud, Akamai, or Fastly, had announced a comparable public resolver validating post-quantum DNSSEC signatures in production.
Do I need to change anything if my site is behind Cloudflare?
No action is required for either feature. Automatic Key Exchange and post-quantum DNSSEC validation are enabled by default across Cloudflare’s network. Site operators who run their own origin infrastructure should confirm their TLS stack supports hybrid X25519+ML-KEM-768 key exchange to get the full benefit of Automatic Key Exchange.
