John Crain, chief technology officer at ICANN, has said the organization intends to speed up work on protecting DNSSEC from future attacks by quantum computers. In an exclusive interview with The Register on October 26, Crain, who was attending an ICANN meeting in Bali, said, "We're going to speed up development." On how much time is left, he said he didn't know whether it was three years or five, but that it was probably not ten. This is not an official migration deadline, nor a definitive prediction of when quantum computers will become practical. DNSSEC uses digital signatures to verify that DNS data comes from a legitimate source and has not been tampered with, and the challenge is defending against the decryption of private keys and the forging of signatures by quantum computers. Cloudflare's public DNS resolver, 1.1.1.1, already supports validating post-quantum signatures. However, migrating the internet as a whole will require ways to carry larger DNS responses and to protect the chain of trust running from the root down to each domain.
How a 2,420-byte signature affects DNS transport
On September 10, 2026, Cloudflare announced that its public DNS resolver 1.1.1.1 now supports validating the post-quantum signature scheme ML-DSA-44. Resolvers process DNS queries on behalf of users and validate DNSSEC signatures. Cloudflare says no quantum computer capable of breaking current cryptography exists yet, and that the move is preparation for a future threat. DNSSEC protects the authenticity and integrity of DNS data; this differs from the role of technologies such as DNS over HTTPS (DoH), which keep the contents of communications confidential.
This migration does not simply mean making conventional RSA or ECDSA keys longer. It requires switching to post-quantum signature schemes built on different mathematics. A major challenge is the size of signatures and public keys. According to Cloudflare's comparison, an ECDSA P-256 signature is 64 bytes, while an ML-DSA-44 signature is 2,420 bytes, about 37.8 times larger. The public key is 1,312 bytes, which also significantly affects DNS response size. That 37.8x figure compares signatures alone, however; it does not mean total DNS response size, traffic volume, or response time grows by the same factor.
This signature size exceeds the limits of UDP, the transport commonly used for DNS. Many DNS implementations cap UDP responses at 1,232 bytes, and the limit recommended by RFC 9715 is 1,400 bytes. These are not absolute limits across all of DNS, but with ML-DSA-44 the signature alone exceeds both values before headers or DNS records are added. That makes it difficult to return signed data in a single UDP response as is done today.
To avoid UDP fragmentation, an authoritative DNS server signals that a response has been truncated, and the querying side typically retries over TCP. In other words, it is not enough to be able to validate the new signatures; the environment must also be able to carry the larger DNS responses reliably. The DNSKEY response, which delivers public keys, is a particular concern, since it contains the keys themselves along with the signature authenticating that record set. During the transition, keys and signatures from both old and new schemes will coexist, and key rollovers may add even more keys, so the impact on traffic cannot be judged from the size of a single signature alone.
Meanwhile, in IANA's DNSSEC algorithm registry, ML-DSA-44 has been assigned algorithm number 18. However, the implementation recommendations for both signing and validation are "MAY," meaning they are not mandatory. The assignment is a step toward deployment, but it does not mean support across DNS as a whole or that IETF standardization is complete.
Running old and new signatures together does not complete quantum protection
If conventional signatures are kept during the transition to preserve compatibility, older validators can continue to validate DNS responses. But if a validator that supports post-quantum signatures also accepts responses backed only by conventional signatures, an attacker able to break that scheme in the future could exploit it. If an attacker can steer validation toward the weaker scheme, the benefit of deploying post-quantum signatures is lost. This is known as a downgrade attack, and it is one of the key problems to address in the move to post-quantum cryptography.
DNSSEC validation does not rest on the signatures of the target domain alone. To confirm that the keys published by an authoritative DNS server are legitimate, validators use the DS record in the parent zone one level up. The DS record contains a hash corresponding to the child zone's public key, so the child's key can be verified through information authenticated by the parent. The mechanism that links this validation from the trust anchor at the DNS root down through each level is called the chain of trust.
Cloudflare says it has introduced a validation policy for 1.1.1.1 that takes this mechanism into account. Specifically, when the authenticated DS record set in the parent zone includes a post-quantum algorithm the validator supports, it requires at least one validation path using a post-quantum scheme to succeed. This prevents validation from being deemed successful on conventional signatures alone, improving resistance to downgrade attacks. Note that this is the validation policy Cloudflare adopted, not standard behavior shared by all DNSSEC validators.
Furthermore, introducing post-quantum signatures in a child zone alone cannot protect the entire chain of trust. If any segment between the root trust anchor and the target domain remains protected only by conventional schemes, it could become a foothold for attack. That is why coordination is essential among authoritative DNS servers and resolvers, as well as the registrars that handle domain registration and the registries that manage parent zones. DS records corresponding to child-zone keys must be registered in the parent zone, and post-quantum protection must ultimately extend all the way to the root.
In its September 10 announcement, Cloudflare also outlined plans to follow its validation support with ML-DSA-44 signing in its authoritative DNS service and support for registrars' handling of DS records. That announcement alone, however, does not confirm later implementation or availability. Making DNSSEC fully quantum-resistant will require technical work by each operator, along with operational arrangements that tie them together.
MTL can make signing more efficient, but TCP traffic remains
Approaches that authenticate multiple pieces of data together are also being considered to ease the burden of large signatures. The ML-DSA-MTL Internet-Draft (draft-03), updated on October 19, 2026, proposes a mechanism based on Merkle Tree Ladders (MTL). In DNSSEC, a set of DNS records sharing the same domain name and record type is called an RRset, and this approach aims to authenticate multiple RRsets efficiently.
In ML-DSA-MTL, a data structure called a "ladder" that authenticates multiple RRsets is signed, and Merkle proofs confirm that each RRset is covered. Processing several RRsets together can spread the cost of generating the underlying signature, and tracking validated ladders may also reduce the burden of repeated validation and data storage. The approach seeks to limit the burden of generating and validating a large signature for each individual DNS response.
However, making signing more efficient is a separate matter from whether DNS responses can be carried over UDP. The only response type defined in the current draft-03 is the "full" response, which contains all the necessary authentication information. Section 10 of the draft states that full responses under this scheme will always exceed a size that can be handled over DNS over UDP. It therefore anticipates more TCP traffic than with conventional schemes, and for clients that want to avoid the cost of retrying over TCP after a UDP query, it recommends sending all queries to the relevant zone over TCP from the start.
It is therefore premature to assume that adopting MTL removes UDP size constraints. That said, this constraint applies to the full responses defined in the October 19 draft; it has not been decided that future extensions would be bound by the same limit. In addition, ML-DSA-MTL remains an individually submitted Internet-Draft, not an official IETF standard, and no DNSSEC algorithm number has yet been assigned to it.
Choosing a signature scheme also requires weighing factors other than data size. In an individual draft on selecting post-quantum DNSSEC algorithms published October 2 by ICANN's Paul Hoffman, he notes that a 650-byte signature might fit in a UDP response if there is only one, but once several signatures are included, a switch to TCP may be needed. The CPU power needed to generate and validate signatures and support in hardware security modules (HSMs), which protect private keys, are also important evaluation criteria. Cryptanalytic scrutiny of security and patent licensing must be considered as well. The draft lays out these selection issues; it is not a document in which ICANN or the IETF has decided to adopt a particular scheme.
How far has DNSSEC's post-quantum migration come?
To judge how far DNSSEC's post-quantum migration has progressed, it is necessary to look separately at validator support, transport, delegation to parent zones, and the chain of trust to the root, not just the number of deployments of new signature schemes. Taking Cloudflare's implementation description, the MTL draft, and IANA's registry together, there is progress at each stage, but the conditions for completing the migration are not yet in place. In particular, reliably transferring 2,420-byte signatures and maintaining safe validation in environments where old and new schemes coexist are challenges that must be solved separately from the signature algorithm itself.
| Stage | Progress confirmed | Remaining challenges |
|---|---|---|
| Validating the new scheme | Cloudflare's 1.1.1.1 announced ML-DSA-44 validation support on September 10. IANA assigned algorithm number 18 | Support for signing and validation in other validators and authoritative DNS servers needs to advance |
| Transferring DNS responses | ML-DSA-44 signatures are 2,420 bytes. The full responses in the October 19 MTL draft also exceed UDP size limits | Support is needed for retrying over TCP and for communication methods that use TCP from the start |
| Validation when old and new schemes are used together | 1.1.1.1 requires a post-quantum validation path to succeed, depending on the authenticated parent DS records | Downgrade attacks to conventional schemes must be prevented and the behavior of each validator managed appropriately |
| Protection from parent zones to the root | The existing mechanism of authenticating child-zone keys through parent-zone DS records can be used | Authoritative DNS operators, registrars, and registries must coordinate to make every level, including the root trust anchor, quantum-resistant |
This table organizes the distinct stages needed for the same migration; it is not an official roadmap or a measure of adoption across DNS. Implementation in validators, the assignment of an algorithm number, and updates to individual drafts are progress at different stages. Nor is it an estimate of communication delays or the number of years the migration will take, derived from differences in signature size.
To evaluate the results of the acceleration Crain described, it will matter not only whether more validators support post-quantum signatures, but also whether large DNS responses can be carried reliably over TCP, whether the weakening of security from running old and new schemes together can be prevented, and whether the chain of trust to the root can be protected. Making DNSSEC quantum-resistant is not just a matter of swapping cryptographic algorithms; it requires the many operators and systems that make up DNS to move together. Only when these efforts come together can the security of not just individual domains but the entire validation path leading to them be assured against signature forgery by future quantum computers.