1.1.1.1 validates DNSSEC signatures produced with ML-DSA-44, the post-quantum signature algorithm standardized by the National Institute of Standards and Technology (NIST). Support is enabled today, marking a first step toward a DNSSEC that survives the arrival of cryptographically relevant quantum computers.
Why DNS needs a post-quantum signature algorithm
DNS answers carry no authentication by default, so an attacker able to forge a response can point users at an address of their choosing. DNSSEC addresses this by signing records; a validating resolver like 1.1.1.1 walks a chain of signed records from the root down to the requested domain and confirms the answer is authentic and unmodified.
Multiple signature algorithms are permitted in DNSSEC, yet nearly every algorithm in use is exposed to a future quantum computer. RSA and ECDSA rest on mathematical problems believed to be infeasible to solve with conventional hardware at deployed key sizes. Should a sufficiently powerful quantum computer be built in 2030, the private key behind such a signature could be recovered and used to mint forged signatures that validators accept.
No such machine exists yet, and DNSSEC is not exposed to "harvest now, decrypt later" collection because it offers authenticity rather than confidentiality. The reason to move early is coordination: any DNSSEC change has to propagate through authoritative servers, registries, registrars and validating resolvers. Responsibility reaches its peak at the top of the hierarchy, where a break aids every zone below it — an attacker who recovers a root zone signing key can forge a validation path downward, breaking once and forging everywhere. ML-DSA-44 supplies a standardized entry point for that migration, and validating it in 1.1.1.1 provides real operational experience for Cloudflare and the wider DNS ecosystem.
The migration is harder than swapping an algorithm
DNSSEC was built to accept new algorithms, so in theory a zone publishes an ML-DSA-44 public key and resolvers learn to verify its signatures. Two practical properties stand in the way: signature size, and the inability to retire the previous algorithm cleanly.
Signature size versus the DNS packet budget
Today's algorithms are compact next to post-quantum ones. ECDSA P-256 yields a 64-byte signature; an ML-DSA-44 signature is 2,420 bytes, almost 38 times larger.
Algorithm | Public key size | Signature size | |
RSA-2048/SHA-256 | 8 | 260 bytes | 256 bytes |
ECDSA P-256 | 13 | 64 bytes | 64 bytes |
ML-DSA-44 | 18 | 1,312 bytes | 2,420 bytes |
The problem is that much of the DNS software stack is sensitive to message size. Messages carried over UDP were originally limited to 512 bytes, and EDNS(0) later let a resolver advertise the largest UDP response it would accept from a nameserver. A conservative UDP payload limit of 1,232 bytes is widely implemented, chosen to fit IPv6's 1,280-byte minimum MTU. RFC 9715 more recently recommended capping DNS over UDP at 1,400 bytes. A single ML-DSA-44 signature blows past that ceiling before the signed RRset, domain names, DNS headers and other DNSSEC records are counted. Fragmenting such a response over UDP is unreliable and should be avoided, so the authoritative server ought to return a truncated answer instead, prompting the resolver to retry over another transport, typically TCP.
DNSKEY responses show the strain most clearly, since they carry the keys a resolver needs to validate the zone. An ML-DSA-44 public key is 1,312 bytes and the DNSKEY RRset also holds a 2,420-byte signature. Because ML-DSA-44 cannot fully replace conventional signing until support is broad, DNSKEY responses may carry both conventional and post-quantum keys and signatures for years, and key rollovers can inflate them further.
Non-UDP transport is routine for a resolver at this scale. Cloudflare Radar data shows roughly 85% of queries to 1.1.1.1 arrive over UDP, while across all services on Big Pineapple — the platform behind 1.1.1.1, which also serves Gateway DNS — about 60% arrive over UDP and the remaining 40% use TCP, DoT or DoH. Those numbers describe traffic to Cloudflare's resolver services rather than how 1.1.1.1 talks to authoritative servers, where large ML-DSA-44 answers can still add TCP retries.
The downgrade risk of dual signing
A zone signed only with ML-DSA-44 is unvalidatable for resolvers that lack support, so the natural path is to publish conventional and post-quantum keys and signatures side by side. Compatibility comes at a price: dual signing alone does not deliver post-quantum security. RFC 6840 states that validators SHOULD accept any single valid path, which lets each resolver pick whichever published algorithm it supports. Once a conventional algorithm such as ECDSA is breakable, the same rule becomes a downgrade route — an attacker forges an ECDSA-only answer and the resolver accepts it even though ML-DSA-44 is supported.
Blocking that route calls for an authenticated signal that a zone must be validated with ML-DSA-44, and 1.1.1.1 takes it from DS records published by the parent zone. When the authenticated DS RRset holds a record for a supported post-quantum algorithm, the signal is present, and 1.1.1.1 applies a deliberately more restrictive local policy: at least one valid post-quantum validation path is required, a conventional path no longer suffices, and validation fails if no ML-DSA-44 path validates. That goes beyond standard DNSSEC validation behavior, but RFC 4035 permits local resolver policy to decide whether extra signatures must be checked and how conflicts are resolved. Conventional signatures stay available to older resolvers while post-quantum-capable resolvers cannot fall back to them.
The signal is only post-quantum secure if ML-DSA-44 deployment and downgrade protection run from the trust anchor through every delegation. Rotating the zone key more often does not close the gap, because an attacker can target a weak key higher in the chain and forge each delegation beneath it.
What still has to be built, and what comes next
Adding an algorithm to DNSSEC is not just a cryptographic question. It requires library implementations, an IANA-assigned algorithm number, support in authoritative servers and validating resolvers, and adoption across the delegation chain. ML-DSA-44 has cleared the first hurdles: NIST standardization, implementations in common cryptographic libraries, a description of its DNSSEC use in the ML-DSA for DNSSEC Internet-Draft, and IANA assignment of DNSSEC algorithm number 18.
Resolver-side validation is an early step but does not by itself produce a complete post-quantum chain of trust. Authoritative servers have to sign zones with ML-DSA-44, registrars have to accept and submit the matching DS records, and registries have to publish them in parent zones. Adoption has to reach the root, whose post-quantum key must become a trust anchor for validating resolvers; any level left without post-quantum protection remains a downgrade point. Signing with ML-DSA-44 is also of limited value while no resolver checks the signatures, which is why defaulting ML-DSA-44 validation on at 1.1.1.1 matters — it makes the operational cost of verification, bandwidth and resolver-to-authoritative TCP use measurable.
Deployability will be probed the way earlier migrations were, using background probes on a small fraction of Cloudflare Challenge Pages to check whether clients on real networks can resolve and reach an ML-DSA-44-signed test domain. Other DNS operators and implementers are invited to test ML-DSA-44 at scale; the resulting measurements will indicate what adjustments adoption requires.
Users of 1.1.1.1 need do nothing: ML-DSA-44 validation happens automatically when a zone publishes the necessary records, and existing DNSSEC zones validate as before.
The next step is the signing side — ML-DSA-44 support in Cloudflare Authoritative DNS and matching DS record support in Cloudflare Registrar, free for all customers — which will allow the full path to be exercised, from generating signatures and publishing DNSKEY records to transporting and validating them through 1.1.1.1.
The dnstest.dev zone can be queried through 1.1.1.1 to see post-quantum DNSSEC in operation:
$ dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssec
;; WARNING: truncated reply from 1.1.1.1@53(UDP), retrying over TCP
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 17546
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 3; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: NOERROR
;; QUESTION SECTION:
;; valid.mldsa44.dnstest.dev. IN A
;; ANSWER SECTION:
valid.mldsa44.dnstest.dev. 0 IN A 188.114.97.0
valid.mldsa44.dnstest.dev. 0 IN A 188.114.96.0
valid.mldsa44.dnstest.dev. 0 IN RRSIG A 18 4 0 20260910114537 20260909104537 23176 valid.mldsa44.dnstest.dev. QoycouhscIX9j1PyO1diodPn5uo8zuPYfGhDcbQWrdBfzWlRUVO9tCDW0awrRLogjgQ3kNuKQvHtD7aLNxyIzfMSt658D8vlW/ntQXdOOr76ewBPSLDcCYZK1NKoO6BJ5U63/Jai783+RJvqXbjWiWbFCeCetYllSHP93+/CV73UA9dl6MP+yvctUG85SF9iId/llmW6+kZdN56fVWcXuR9guMILTbaBM/B5RFDHdd4om++uLywhBd0sWloYWndS/TkOpOYobfoqR2L8+Q4KUaJQ3772OFQ86xD5ibJpQmmXobba2/VCwvpAf518EzobKItEXhw5abg8KTHgJyDAIzX1UBxflfe+BPPicL9yWBnib+IjYhoTmJR8Y5ziNztB5ZGoLEoayrla3BO6X5zlFgJ8zesqewYbgA9/LIprPKXpFYnPuasfE8+8tb74rk4gqFcLWbzxnb8YRfio9ztfy9nNGSk40HE0U8ZNaGR3TYV1nfHln3TXuHEg/fG4rbNB7EyTFrES9KxIW2CsZGKkDJUyDAb7tP3m6fC9u/hgr5trXipx3ElLOtnFRBfCVt9dlzwtkrDp5YSqD6eeAIXSFvNj93pbLzLE8DnbdzcptzucWdw9E/BdtIhXxz5STDCKWZkNrJCBGweqKPPfouyTNXWild/EFN6p2tkVZWUKOdQcWHQOFnauZFpgrqmbNjStrux75LbpsU7ly2+Z+x8F5rp+t4t1C4W8+ugR1v9GZ7eWsp1McJLMJCjpoxFPDSfhR/Et7A3WuJL+RnhOxdYAPMO2qHCprxvDWFtoxGrYWdyw/k33oTO4TmubewRVhWHibA1twXz18JQ56ZreoHG/B5eG+IIAxh8epdqdzONf4Hs7qqMFbmrAwUskvbimpQzCdPEpvky+s2wO0qq6Rt6YbGCOed2hDQ4DjLzCYQHokMT573zcQeHNsYpmLfmv48JKmj8TrGhpj1kUgkIR6kE1xo7Jikol8WcWqDnhdq654HSGh75yKlfl/MeuLWq80HqOFqILYoFqKuk7t8nMte6crSRhksevyMhtAgUiN4q1cAdpCmO1Imx2rZJ0NOH36KCtKCFBUYpX1CYNYykhWJZiZ9eLo0VTjW8eESb+D+sZhC2C1JnP6+y/4a5PwwWYvmrlV+HP6E4mDpe1s76KqD4qX7EhaRTxip2U9RQV3I1LEv19Uy6GQ7on2oBT/hGMFbLbko2PTsCADu5k/xiJOut2uNQJ4NcYrMKWT7eyG3SNjCZdd5vl83DR7TgWpPfCOn4Q5q0WxtI1flRSmSv8CfWlT2rWPtBkFKIzg3QNsAovUkI+Jcv/SXuZ2HqxTXkG3JhQrtLDJsrWjycdOqxAzx6MGWew2pQsxDM+kKZEMezD8YiUgJ3GqjSxDTXN53eAW6pk5jTxGlOE6VuLqUoeI6vtBiG8DTYxy4v2e24QlGiV33VcNU0z0T4YEYaIWgpZtjfOj+QuPa5WskuyW2v/lbO3LlCFnEDC6FrmrxCgspizc1367obHuvX7LhmWwZN3zKrtsSeVXYwqYBxVz4o14ILbm1GiQvAvEjXx0U51drKDtJY+bKuel68+YLx8CZEITsCXFR3AqVD8Okz3aj/k9WMfORa3nT0B51f9s+7JnDpYtsvDdJlVEX4pSWX1Zrp68U8e75i+Y99NITT4zyCGUywWhvkEahHSa9WvLOsA6HPShizzTjFKCSIRJD2KePfjjuubCzi8fk/R4lTZk9agPBUDrjorlQb3rqmiF8AZCf/OKj4uzJ4eLcTVHN0ltWTtmoIZXX/0wilDEiEHeozZ5fHT0U3MwpG9cuojEqOr2m8OzsPFYN/i8zf38SDj6nJbb3gZlG5XYj7R/SaW3Dw7nm014d09vy36XlFnnz9RKCsTBvyRPhNSNdV+bX85PnVBEX7AU/IxENUD1+68X9VbAPZGCMKHHIudpsX2ue+wGYh58VtchTQdJYV+09RM19EXvYtl1zXs1ZzdwwKEpnVZ93WT766nacMhr/RHVcb9xK2J8eOfH/upYWZoEhIEEUsA9PGPpAIcSmlFKiU54/pyF/cMp+SmgidNxZ7UxW12HxHD4k75et7/S66be2X6e9jjlxFy4N3AoMifSVu1d5ZnBa2uy5/qA/P4Hl0kabpANSC5EtysKEOmFrIG2Nis0ZjxARBgl8VdXPTrGzK9gPfbi6XRGVBlidBAwNvJwGexyNXi8waaYlfmNaFGgpOK0UU15I5ecaDdPfCXmywjFN6y3aNpvZL875WNqeuuUx4hCacufI4OG4ci7Gqp3v4C91BAZQowjbSm4xNEoRbgxAiCA/GNrjnN3H//trG4Vpb4c+9Dp4cGaaBdHS5VmdBN3Qjpqu5DF5nE34bw6HWYGBXIP/pULWC2Mks2ILoMFDCt70698/mUvyNT0OFmhuWmFl6FBVkrtdpNYnm3BPOqpFkP5c8HCCJ9EHhIv3GPTPKfx39exEzheU3/uUrzwuhFqB+F89eEcnXVhzZ/VdTIlSsem6gsmENOQnBGQEooKpLoUAkXIyQn0XFaGOSHplMmevPGp1K8AakA97pQI1EhPutZEet5gHYMz3SX9cfbwBsBnyMVnrEY8wY1dfX4bR8OpVx0+EDQotkD1R9DEa4hyuATkVrgQJTFg4TJJE/p2MxG53n3k0pMFK4LA+B0vwqciKYNfgzmfUIW9zDBgZ/ikuRl7UTnHxKBFkDVR6pJLEg1tf34VnkJU8pkrBTndsCTtvxOhkLoLI5vRBS+zVsuJrGeIV2hSHqVzqdX8PzJZSO/wjDcp1341koG23JC65Uah/Ce06LSUSTOE1eWcp+b2iUpaFTl3FH3Nj487f2FDCHzXC9msaM7S1RlmvCssh/4LZXW4Y0QyB7ZzclOptpKU/9R5yePe8nOOXwDXAQaRl3iVt8ayhLcN5BNwqYvhS34ieBgYU2RX3nmFDrX4b9Ph++06DGC97owZXFZNDQQJ/jekvnL37gnyWnDrNWdM70lp/0mmcwsM+z79XAN8LQJjpPfxWJhkej5LSGzrqV9Zos6t15N5LLAfxydjoiviQVgOBiG45LM1gTOwXbyOsjT8isMdqV/bCf2Kdaj34CF1TKa3+yOtw0fKz9DXnaIjJbKAwkfLTRvf5ClqKy51QgdRkllam9zfH6cnaOs7QEEDQ8SQUVbiaW0vMvO0Pf6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoXJjc=
;; Received 2563 B
;; Time 2026-09-09 13:45:37 CEST
;; From 1.1.1.1@53(TCP) in 20.7 msA resolver check is available at Is your DNS resolver post-quantum ready?, and ML-DSA-44 software support is tracked by the community on GitHub.
