A sufficiently powerful quantum computer could break RSA and ECDSA, the cryptographic algorithms that underpin DNSSEC, TLS certificates, DKIM signatures, and virtually every other security mechanism that protects DNS infrastructure today. When that happens, an attacker with a quantum computer could forge DNSSEC signatures, issue fraudulent certificates, and spoof email authentication, all without needing to compromise any keys or servers.
The question isn't whether this will happen. It's when. And the timeline matters more than most organizations realize, because of a threat that exists right now: "harvest now, decrypt later." As the joint CISA, NSA, and NIST factsheet on quantum readiness warns, cyber threat actors could be targeting data today using a "harvest now, decrypt later" operation, intercepting and storing encrypted traffic with the expectation that quantum computers will eventually allow them to decrypt it. For DNS, this means that DNSSEC-signed records captured today could be retroactively forged once quantum capabilities mature.
NIST finalized its first post-quantum cryptography standards in August 2024: ML-KEM for key encapsulation, ML-DSA for digital signatures, and SLH-DSA as a conservative hash-based signature alternative. Under the transition timeline in NIST IR 8547, quantum-vulnerable algorithms like RSA and ECDSA will be deprecated by 2030 and disallowed entirely by 2035.
For DNS infrastructure, this means a roughly 10-year transition window during which DNSSEC signing algorithms, DKIM key types, TLS certificate chains, and the entire cryptographic foundation of DNS trust must migrate to post-quantum alternatives.
This guide explains what's changing, why DNS is particularly challenging to migrate, what the current state of PQC for DNS looks like, and what organizations should be doing now to prepare.
What Quantum Computing Threatens in DNS
To understand the impact, you need to know which DNS security mechanisms depend on the algorithms that quantum computers will break.
DNSSEC
DNSSEC uses digital signatures (typically RSA or ECDSA) to authenticate DNS responses. Every signed zone has DNSKEY records containing public keys, and RRSIG records containing signatures over each record set. Resolvers verify these signatures to ensure responses haven't been tampered with.
A quantum computer running Shor's algorithm could derive private signing keys from the published public keys, allowing an attacker to forge valid DNSSEC signatures for any zone they can observe. The entire chain of trust, from root zone to TLD to individual domains, would be compromisable.
DKIM
DKIM email signatures use RSA (or Ed25519) keys published in DNS TXT records. A quantum computer could extract the private key from the published DKIM public key, enabling perfect email forgery that passes DKIM verification. Since DKIM keys are published in DNS and rarely rotated, they're particularly exposed to harvest-now attacks.
TLS Certificates
TLS certificates verified via DANE/TLSA records in DNS depend on RSA or ECDSA. CAA records restrict certificate issuance, but the certificates themselves use quantum-vulnerable algorithms. Once quantum computers can forge certificates, the TLS trust model breaks regardless of DNS-level controls.
DNS-over-HTTPS and DNS-over-TLS
Encrypted DNS transport (DoH and DoT) protects query privacy using TLS. The key exchange typically uses ECDH, which is vulnerable to Shor's algorithm. An attacker capturing encrypted DNS traffic today could decrypt it retroactively once quantum capabilities are available, revealing query patterns and browsing histories.
Why DNS Is Particularly Hard to Migrate
Post-quantum migration for DNS faces unique challenges that don't apply to most other cryptographic systems.
Signature Size
This is the fundamental problem. DNS was designed for small packets. The standard UDP response size is 512 bytes, extended to approximately 1232 bytes with EDNS0 (the practical limit that avoids IP fragmentation issues). Current DNSSEC signatures fit comfortably within these limits: an RSA-2048 signature is 256 bytes, and an ECDSA P-256 signature is 64 bytes.
Post-quantum signatures are dramatically larger. According to the IETF PQC DNSSEC Strategy draft, ML-DSA signatures range from 2,420 to 4,627 bytes, and SLH-DSA signatures range from 7,856 to 49,856 bytes. Both exceed the practical UDP packet limit, meaning every DNSSEC-signed response would require TCP fallback, dramatically increasing latency and resolver load.
FN-DSA (based on FALCON (PDF), expected as FIPS 206) offers smaller signatures of around 666 bytes at the 512-bit security level, which is more feasible for DNS. But it's not yet standardized and has complex implementation requirements due to its use of floating-point arithmetic in signing.
Response Amplification
Larger DNSSEC responses create a DNS amplification risk. DNS amplification attacks exploit the ratio between the size of a DNS query (small) and the size of the response (large). Post-quantum signatures would increase response sizes by 5-50x, making DNS an even more attractive amplification vector for DDoS attacks.
Ecosystem-Wide Coordination
DNSSEC migration requires coordination across the entire DNS hierarchy. The root zone must migrate. Every TLD must migrate. Every authoritative nameserver must support the new algorithms. Every recursive resolver must be able to validate the new signatures. This isn't a single organization's decision. It's a global infrastructure upgrade that requires the root zone operators, TLD registries, DNS software vendors, resolver operators, and millions of domain owners to move in a roughly coordinated fashion.
Backward Compatibility
During the transition, zones will need to support both classical and post-quantum signatures simultaneously (a "hybrid" approach) to maintain compatibility with resolvers that haven't been upgraded. This doubles the already-enlarged signature payload, compounding the size problem.
Current Approaches and Research
The DNS and cryptography communities are actively working on solutions to the size problem.
MTL Mode (Merkle Tree Ladder)
Verisign has proposed MTL (Merkle Tree Ladder) mode, which uses a Merkle tree structure to reduce the per-response signature size. Instead of including a full PQC signature in every DNS response, MTL mode distributes authentication data across a tree structure, with individual responses carrying smaller "authentication paths." This approach significantly reduces the bandwidth impact while maintaining quantum-resistant security.
FN-DSA / FALCON
FN-DSA produces the smallest signatures among NIST's selected algorithms (666 bytes at the 512-bit level). This makes it the most DNS-friendly option, approaching the size of current RSA-2048 signatures. NIST is expected to finalize the FN-DSA standard (FIPS 206) in the near future, and early implementations in BIND and CoreDNS are being tested at IETF hackathons.
NIST's Additional Signatures Process
Recognizing that current PQC signatures are too large for many protocols, NIST has initiated a second round of evaluation for additional signature algorithms with smaller output sizes. Candidates include MAYO, SNOVA, and CROSS. If successful, these could provide signatures compact enough for DNS without requiring structural changes like MTL mode.
Experimental Deployments
Researchers at IETF hackathons (IETF 122 and 123) have extended DNS software including BIND, NSD, and CoreDNS to support PQC algorithms. These experiments have produced real-world performance data showing the impact of larger signatures on resolution latency, TCP fallback rates, and resolver memory usage. The results confirm that ML-DSA and SLH-DSA are impractical for DNS without size reduction techniques, while FN-DSA is more feasible but not yet standardized.
The Timeline
NIST's transition timeline provides clear milestones:
- 2024: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) finalized
- 2025-2026: FN-DSA (FIPS 206) expected to be finalized. Additional signature algorithm candidates evaluated. Early PQC DNSSEC implementations tested.
- 2027-2030: Planned DNS root key rollover with potential PQC integration. Organizations should be in active migration planning.
- 2030: NIST deprecates RSA-2048 and ECDSA-224. Organizations using these algorithms need viable alternatives in place.
- 2035: NIST disallows RSA, ECDSA, and EdDSA entirely. All DNSSEC zones, DKIM keys, and TLS certificates must use post-quantum algorithms.
This 10-year window sounds long, but the DNS ecosystem's coordination requirements mean that migration planning should start years before the deadlines. Organizations that wait until 2030 to begin will face a compressed, high-risk transition under deprecation pressure.
What "Harvest Now, Decrypt Later" Means for DNS
The most urgent quantum threat isn't the future ability to forge signatures in real time. It's the present-day practice of recording signed data for future exploitation.
DNSSEC signatures are transmitted in the clear over standard DNS. Any network observer (ISP, state actor, or compromised resolver) can record DNSSEC-signed responses today. When quantum computers become available, they can retroactively extract signing keys from these captured signatures, potentially enabling:
- Reconstruction of historical DNS changes for intelligence purposes
- Forgery of backdated DNSSEC signatures for use in legal or forensic contexts
- Extraction of DKIM private keys from captured DKIM public key records, enabling forgery of email that "validates" against historical keys
For high-value targets (government, financial, defense, critical infrastructure), this threat is immediate even though the quantum capability isn't. The data being harvested today will still be valuable in 10 years.
What Organizations Should Do Now
1. Inventory Your Cryptographic Dependencies
Start by understanding what algorithms your DNS infrastructure uses today. Which DNSSEC signing algorithm does your zone use (RSA, ECDSA, Ed25519)? What key type do your DKIM selectors use? What algorithms do your TLS certificates rely on?
Use the DNS lookup tool at dnsassistant.com/tools to query your DNSKEY records (showing your signing algorithm), DKIM TXT records (showing key type and length), and CAA records (showing authorized CAs). The Free Domain Risk Report provides a comprehensive scan including TLS certificate details.
2. Rotate DKIM Keys More Frequently
DKIM keys are published in DNS and are directly exposed to harvest-now attacks. If you're rotating DKIM keys annually (which many organizations don't do at all), consider increasing the rotation frequency. Shorter-lived keys reduce the window during which a captured key is useful to a future quantum attacker. Moving to 2048-bit RSA keys (or Ed25519) doesn't solve the quantum problem, but it maximizes classical security during the transition.
3. Monitor DNSSEC Algorithm Changes
When your DNS provider or TLD registry upgrades their signing algorithms (whether to a stronger classical algorithm or an early PQC deployment), your DNSKEY and DS records will change. DNS Assistant monitors these records and alerts you to changes, ensuring you have visibility into algorithm transitions that affect your domain.
4. Track the Standards
The PQC landscape is evolving rapidly. Follow NIST's PQC standardization process, the IETF's PQC DNSSEC work (particularly the PQC DNSSEC Strategy draft), and your DNS provider's roadmap for PQC support. Cloudflare, Google, and Verisign are all actively involved in PQC DNSSEC research.
5. Plan for the Size Impact
If your DNS responses are already close to the 1232-byte EDNS0 limit (common for domains with many TXT records, like SPF and DKIM), PQC signatures will push you well over the limit. Audit your DNS response sizes now and plan for optimization: consolidating TXT records, reducing unnecessary records, and ensuring your infrastructure supports DNS over TCP efficiently.
6. Assess Your PQC Readiness
DNS Assistant includes a PQC readiness assessment that evaluates your domains' current cryptographic posture and identifies areas that will need attention during the post-quantum transition. This gives you a baseline for migration planning and helps prioritize which domains and records to address first.
The Bigger Picture
Post-quantum migration for DNS is one of the most complex infrastructure transitions the internet has ever faced. Unlike the HTTPS migration (where each website could upgrade independently) or the IPv6 transition (where dual-stack provides backward compatibility), DNSSEC's chain of trust requires coordinated migration across every level of the hierarchy.
The good news is that the cryptography community, DNS vendors, and standards bodies are actively working on solutions. MTL mode, FN-DSA, and NIST's additional signature algorithms all show promise for making PQC DNSSEC practical.
The bad news is that the timeline is fixed. NIST's 2030 deprecation and 2035 disallow dates are published. Organizations that don't begin preparation now will face a compressed, high-risk migration later.
The organizations best positioned for this transition are the ones with full visibility into their DNS cryptographic posture: what algorithms they use, where their keys are published, when their certificates expire, and how their DNSSEC chain of trust is configured. That visibility is the foundation for any migration plan.
DNS Assistant provides that visibility today, and will continue to evolve as PQC standards mature and DNS providers begin deploying quantum-resistant algorithms.
Start with a free scan: Use the DNS lookup tool to check your current DNSSEC algorithms and DKIM key types. Run a Free Domain Risk Report for a comprehensive view of your DNS and TLS cryptographic posture.
For continuous monitoring and PQC readiness assessment, sign up at dnsassistant.com.
Further reading:
Top comments (0)