>samit_hota
Back to security news

Security News · SN-2026-600

HIGHOPEN

ICANN Accelerates Post-Quantum DNSSEC Transition Over Decryption Concerns

Affected: DNSSEC · DNS resolvers · ICANN · IETF · Regional Internet Registries

Samit Hota·
#news#vulnerability-disclosure#icann

Internet governance leadership is shifting timelines for securing the Domain Name System against quantum decryption attacks. Speaking at ICANN’s annual meeting in Bali, ICANN Chief Technology Officer John Crain stated that preparations for a post-quantum DNSSEC transition must happen significantly faster than previously assumed, compressing what was once viewed as a ten-year migration strategy down to a three- to five-year runway.

The urgency stems from advancing capabilities in quantum computing, where commercially viable systems running Shor’s algorithm threaten to collapse the public-key infrastructure underpinning global internet integrity.

The Quantum Threat to DNSSEC Architecture

DNSSEC (Domain Name System Security Extensions) protects the integrity of DNS lookups by adding cryptographic signatures to DNS records. Authoritative name servers publish DNSKEY records containing public keys, which are used to validate RRSIG (Resource Record Signature) responses. This mechanism prevents cache poisoning, DNS spoofing, and man-in-the-middle attacks.

Current DNSSEC deployments rely almost universally on conventional asymmetric algorithms, primarily RSA and Elliptic Curve Cryptography (ECDSA P-256 and Ed25519). A cryptographically relevant quantum computer (CRQC) will be capable of deriving private keys from published public keys in polynomial time.

If an adversary breaks the private key for a domain, top-level domain (TLD), or the DNS root zone itself, they can forge valid RRSIG records for any DNS response. Because recursive resolvers evaluate cryptographic signatures to establish trust, forged signatures from a compromised key would allow seamless, undetected redirection of web traffic, email delivery, and API endpoints across the global internet without triggering validation errors.

Transport Bottlenecks: Payload Sizes and TCP Fallback

Transitioning DNSSEC to post-quantum cryptography (PQC) presents severe protocol-level challenges that extend beyond simply swapping cryptographic algorithms. Post-quantum algorithms standardized by NIST—such as ML-DSA (Dilithium), Falcon, and SPHINCS+—require public keys and signatures that are orders of magnitude larger than RSA or ECDSA equivalents.

The legacy DNS architecture relies primarily on UDP transport for speed and low overhead. While Extended DNS (EDNS0) expanded the historical 512-byte UDP packet ceiling, modern operational guidance caps EDNS0 payload sizes around 1,232 bytes to avoid IP fragmentation, which causes dropped packets and introduces DNS amplification vulnerabilities.

PQC keys and signatures routinely exceed these MTU boundaries:

  • Injecting multi-kilobyte post-quantum public keys and signatures into DNSKEY and RRSIG records will cause responses to exceed UDP payload limits.
  • Oversized responses force authoritative servers to set the Truncation bit (TC=1), instructing recursive resolvers to drop transport down to stateful TCP on port 53.
  • Shifting a substantial percentage of global DNS resolution from stateless UDP to stateful TCP overhead imposes heavy CPU, connection state, and latency burdens on recursive resolvers and authoritative name servers worldwide.

As Crain noted, ensuring the global internet infrastructure can reliably process multi-packet TCP fallback at scale is an operational hurdle that will require years of standardization work across ICANN, the Internet Engineering Task Force (IETF), and software vendors.

Governance Reforms and High-Trust Domain Targeting

Beyond post-quantum preparations, ICANN and regional bodies announced structural updates to internet governance and domain security oversight during the Bali proceedings.

Regional Internet Registry (RIR) Reform

Jia-Rong Low, chair of the Number Resource Organization (NRO), outlined revisions to Internet Coordination Policy 2 (ICP-2), the foundational rules governing the world’s five Regional Internet Registries (AFRINIC, APNIC, ARIN, LACNIC, and RIPE NCC). Triggered by protracted management and legal crises at AFRINIC that threatened the registry’s stability, the revised ICP-2 document expands beyond initial registry formation to define four distinct operational stages:

  1. Recognition of new registry entities.
  2. Audit protocols for operational health.
  3. Emergency continuity operations during governance failures.
  4. Derecognition frameworks.

The draft positioning ICANN as an independent overseer is expected to complete final review by late 2026.

Category 1 GTLD Abuse Analysis

Siôn Lloyd, ICANN’s principal security, stability, and resiliency scientist, shared research on domain abuse trends in “Category 1” Generic Top-Level Domains (gTLDs)—strings associated with regulated sectors such as .bank, .doctor, .pharmacy, and .university.

Lloyd’s investigation revealed that Category 1 domains experience a 45 percent higher probability of being targeted by DNS abusers than standard domains, as malicious actors seek authoritative-sounding TLDs to enhance the credibility of phishing and social engineering campaigns. However, due to stricter registry-level vetting, overall abuse volume on these TLDs remains low relative to open registries.

To counter automated exploitation, ICANN is advancing two policy initiatives: Policy Development Process 1 (PDP1), which mandates strict registrar intervention against domain owners facilitating abuse, and PDP2, aimed at regulating automated high-volume domain registrations.

Found something similar in your stack?

Let's find out before it becomes an incident.

Book an advisory call