Post-Quantum DNS Security: DoH, DoT, DoQ and DNSSEC

TL;DR

Quantum computers will not break DNS today, but they will reshape DNS security. ICANN’s Office of the CTO set out the baseline in “Quantum Computing and the DNS” (OCTO-031v2, 22 April 2024), and the standards picture has moved on considerably since then:

Encrypted DNS (DoH/DoT/DoQ) is the first area to move to post-quantum cryptography (PQC), because its TLS and QUIC key exchange is exposed to harvest now, decrypt later attacks. ICANN recommends these protocols follow the web community’s choices, and the web has now chosen: hybrid X25519MLKEM768 key exchange, standardised in IETF RFC 10024 (August 2026).
DNSSEC faces a later, different risk: a future quantum computer could forge signatures. It is not exposed to harvest now, decrypt later, and ICANN advised in 2024 that there was no need to rush. Work has since accelerated, with several IETF Internet-Drafts and the first public resolver validating post-quantum DNSSEC signatures, but no PQC algorithm is yet standardised for DNSSEC.
The priority for enterprises: PQC deployment for encrypted DNS now, and algorithm agility plus long-term readiness for DNSSEC.

Why Quantum Matters for DNS Security

A conversation with a colleague about the impact of post-quantum cryptography on DNS security led me to revisit ICANN’s paper, “Quantum Computing and the DNS”. ICANN judged it very unlikely that a cryptographically relevant quantum computer (CRQC) would be built within the next decade, and possibly not for many decades. Since then, the wider security community, and governments in particular, have adopted a much more cautious planning horizon.

The Timeline Has Tightened

No standards body has put a date on “Q-Day” (also called Y2Q), the point at which a quantum computer could break RSA and elliptic-curve cryptography, the algorithms underpinning DNSSEC, TLS, certificates and DNS privacy protocols today. Estimates vary widely: the US Government Accountability Office reported in October 2026 that most industry experts believe a CRQC will be developed, possibly as soon as the 2030s. Resource estimates have also fallen: in May 2025 Google Quantum AI’s Craig Gidney estimated that RSA-2048 could be factored with fewer than one million noisy qubits.

What has changed decisively is policy. Governments have now put dates on the migration: NIST’s final IR 8547 (27 October 2026) deprecates quantum-vulnerable public-key algorithms after 2030 and disallows them after 2035; the UK NCSC expects high-priority migration by 2031 and completion by 2035; and the EU roadmap targets high-risk use cases by the end of 2030.

Even if Q-Day lands later, the risk horizon has shifted, because planning and migration cycles in enterprises often span many years.

Encrypted DNS (DoT / DoH / DoQ): The First and Most Urgent Priority

Encrypted DNS relies on TLS (DNS-over-TLS, RFC 7858; DNS-over-HTTPS, RFC 8484) and QUIC (DNS-over-QUIC, RFC 9250) for confidentiality. Unless post-quantum key exchange is enabled, these sessions are protected by classical key exchange (elliptic-curve Diffie-Hellman such as X25519 in TLS 1.3 and QUIC, and sometimes RSA key transport in older TLS 1.2 deployments), which leaves them exposed to one of the most significant quantum-era threats:

Harvest Now, Decrypt Later (HNDL) Threat

Attackers can record encrypted DNS traffic today, store it and decrypt it later, once they have access to a CRQC.

The implications for enterprises are serious. Decrypted DNS history could be used for:

Mapping internal service discovery
Exposing user behaviour and metadata
Revealing internal application dependencies
Weakening overall Zero Trust posture
Compromising DNS privacy at scale

Why encrypted DNS must transition early

TLS is the first protocol to receive standardised PQC upgrades. In August 2026 the IETF published RFC 10024, which standardises three hybrid key agreement groups for TLS 1.3, including X25519MLKEM768 (X25519 combined with ML-KEM-768). Cloudflare reported in September 2026 that X25519MLKEM768 is preferred by most major browsers and that around 70% of browser-generated traffic reaching its network already uses hybrid ML-KEM. Because QUIC uses the TLS 1.3 handshake, DoQ can use the same groups, and DoH sent by a browser typically benefits from the browser’s own TLS stack.

Support elsewhere is uneven. Operating-system stub resolvers, DoT and DoQ clients, forwarders and resolver software adopt new TLS libraries at different speeds, so check what your endpoints actually negotiate rather than assuming. Our free DNS PQC compliance check tests whether a public DoH, DoT or DoQ server supports post-quantum key exchange.

The UK NCSC’s updated TLS guidance (15 October 2026) recommends hybrid and pure post-quantum options, notes that TLS 1.3 is the only version that supports PQC, and advises organisations to make the move now. For encrypted DNS, that makes PQC a near-term priority, not a long-term one.

DNSSEC: Longer Runway, but Preparation Starts Now

DNSSEC ensures authenticity and integrity in DNS services, not confidentiality. It is not vulnerable to HNDL attacks, but it is vulnerable to future quantum forgery, where an attacker with a CRQC derives private keys from public DNSSEC keys and signs malicious records.

ICANN’s 2024 view was that CRQCs were very unlikely within a decade and that waiting would let the DNSSEC community choose signature algorithms better suited to DNS. The core problem is size. Classical DNSSEC signatures are small (an ECDSA P-256 signature is 64 bytes), while DNS over UDP is generally kept to responses of about 1,232 bytes. The NIST post-quantum signature standards are much larger:

ML-DSA (FIPS 204): signatures of 2,420 to 4,627 bytes; an ML-DSA-44 public key is 1,312 bytes.
SLH-DSA (FIPS 205): signatures of 7,856 to 49,856 bytes.
FN-DSA (Falcon): far smaller (around 666 bytes at the lowest security level), but its standard, FIPS 206, is still being developed by NIST.

Larger responses mean more truncation, more fallback to TCP, extra latency and new denial-of-service considerations. Work to address this has accelerated since 2024:

In September 2026, Cloudflare’s 1.1.1.1 resolver began validating DNSSEC signatures made with ML-DSA-44. Cloudflare notes its test responses exceed the UDP budget and are retried over TCP, and that a full post-quantum chain of trust would need the root and every parent zone to adopt it.
Verisign has developed Merkle Tree Ladder (MTL) mode, which replaces most per-record signatures with short Merkle inclusion proofs, and university, SIDN Labs and IETF hackathon work has prototyped ML-DSA, Falcon, SLH-DSA and SLH-DSA-MTL in BIND, NSD and CoreDNS.
At the IETF, the proposals remain individual Internet-Drafts with no formal standing, including ML-DSA for DNSSEC (draft-westerbaan-dnssec-mldsa) and Post-Quantum Cryptography Strategy for DNSSEC (draft-sheth-pqc-dnssec-strategy, from Verisign Labs, Virginia Tech and NLnet Labs, revised October 2026), which proposes deploying both a conservative algorithm in a size-reducing mode such as MTL and a smaller drop-in algorithm.

So DNSSEC migration should be carefully planned, not rushed. But a DNSSEC algorithm change has to propagate through signing software and HSMs, registries, registrars, DNS operators and validating resolvers, and NIST will disallow today’s quantum-vulnerable signature algorithms after 2035. DNS service providers, TLDs, registries and enterprises should therefore:

Ensure algorithm agility now
Prepare for PQC signature adoption once an algorithm is standardised for DNSSEC
Understand the impact of larger signatures on DNS packet sizes and TCP fallback
Evaluate potential performance bottlenecks

In our assessment, broad DNSSEC transition to PQC is unlikely to begin before the late 2020s and will mostly take place in the 2030s.

While DNSSEC migration is not immediate, architectural preparation must begin now.

Sinevis Recommendations: A Phased Approach

Phase 1: Discovery & Assessment

Identify all TLS- and QUIC-based DNS components (DoH, DoT, DoQ)
Map internal DNS architecture and traffic flows
Assess DNSSEC dependencies, signing keys and HSMs
Evaluate vendor PQC readiness

Phase 2: Design a Post-Quantum DNS Roadmap

Prioritise encrypted DNS PQC migration
Build agility into DNSSEC infrastructure
Develop certificate and PKI transformation strategy
Establish enterprise cryptographic governance

Phase 3: Pilot and Deployment

Deploy hybrid key exchange (X25519MLKEM768) in controlled environments
Measure performance impact and adjust architecture
Begin staged rollout of PQC-capable DNS resolvers
Engage with registries and DNS operators on PQC timelines

Phase 4: Governance and Continuous Monitoring

Track NIST and IETF PQC standards
Review DNS cryptography annually
Update risk posture and controls based on PQC progress
Establish quantum-era incident response considerations

Quantum computing may still be years away, but the operational impact is immediate. DNS, as a foundational layer of the Internet, cannot be migrated overnight.

Organisations that begin preparing now will avoid emergency transitions, operational instability, and compromised data confidentiality after Q-Day.

A cryptographic inventory is the starting point. Enterprise Cryptographic Exposure Management platforms such as Quantum Sentinel support PQC discovery, a cryptographic bill of materials (CBOM), exposure assessment and migration planning. For a quick external view, try our free DNS PQC compliance check.

Sinevis is ready to support your post-quantum readiness journey with assessments, architecture reviews, DNSSEC agility design, and a full PQC migration roadmap.

Check our Post-Quantum Cyber Readiness services, or read our late-2026 PQC migration readiness update.

The Post-Quantum Future of DNS Security: What Enterprises Need to Know Now