DNSSEC faces a post-quantum traffic problem

DNSSEC, the system that uses digital signatures to verify that DNS answers are authentic, faces a transport problem if it adopts post-quantum cryptography. Larger signatures could make many responses too large for ordinary UDP delivery, forcing recursive resolvers to retry queries over TCP.

The concern comes from the possible arrival of a cryptographically relevant quantum computer, or CRQC, powerful enough to derive private keys from exposed public information within a useful period. Quantum computers remain at a very early stage, and building them has been slow and expensive. However, Peter Shor’s 1994 algorithm showed that sufficiently capable quantum computers could threaten RSA and elliptic-curve cryptography, known as ECC.

When a CRQC will exist is unknown. The year 2030 has been discussed, although APNIC describes it as an optimistic possibility rather than an established forecast. The issue is already relevant for information that must remain secret for two decades. An attacker could capture encrypted data now and decrypt it later, a practice known as Harvest Now, Decrypt Later, or HNDL.

Digital signatures have a related weakness. If an attacker calculates the private key belonging to a signing key pair, they could impersonate its owner. The risk depends partly on how long that key remains in use. An ICANN publication from 2022, “Observing DNSSEC Key Lifecycles” (OCTO-035), found that top-level-domain Key-Signing Keys, or KSKs, generally remained in use for one or more years, while Zone Signing Keys, or ZSKs, were generally used for one or more months.

Rotating keys more frequently could provide an initial response, such as replacing a ZSK monthly and a KSK yearly or every six months. But faster rotation would not be enough if quantum computing advances quickly. DNS operators would eventually need post-quantum cryptographic algorithms, known as PQC, in their DNSSEC configuration.

The immediate engineering challenge is size. APNIC compares DNSSEC algorithm 13, ECDSA P-256 with SHA-256, with algorithm 18, ML-DSA-44. The ECDSA public key is 32 bytes, its private key is 32 bytes and its signature is 65 bytes. ML-DSA-44 uses a 1,312-byte public key, a 2,560-byte private key and a 2,420-byte signature.

In APNIC’s example, a DNS query for a name signed with ECDSA P-256 produced a 191-byte response, including a 65-byte signature, which fitted in one unfragmented UDP packet. The same query using ML-DSA-44 produced a 2,551-byte response. The recursive resolver returned a truncated UDP response, so the stub resolver had to establish a TCP connection and repeat the query. The transaction grew from two UDP packets to ten packets, including the truncation message, TCP handshake and connection shutdown.

IP fragmentation might appear to solve the problem because an IP packet can be as large as 65,536 bytes. But fragmentation is unreliable and risky on both IPv4 and IPv6. APNIC cites DNS Flag Day 2020, which warned that fragmented DNS messages can fail to arrive and may also allow parts of a message to be spoofed without easy detection.

The original DNS design limited UDP payloads to 512 octets. Extension Mechanisms for DNS, or EDNS, later allowed a requester to advertise the largest UDP payload it could reassemble. Until around 2019, 4,096 octets was often suggested as a starting point. DNS Flag Day 2020 instead recommended an EDNS UDP buffer size of 1,232 bytes to avoid fragmentation on nearly all current networks. The relevant specifications are RFC 6891 and RFC 4035.

APNIC Labs measured EDNS buffer sizes over seven days ending 3 November 2026, using 36 billion queries from 245 million enrolled end users. Most queries used 1,410 bytes. APNIC calculated that 75.2% of queries used a buffer size likely to avoid fragmentation within a 1,500-byte IP packet, while 24.8% indicated that the recursive resolver could accept a larger, fragmented response. The measurement does not mean that one quarter of responses will necessarily be fragmented, because authoritative servers also set their own limits. The smaller limit controls whether a response is complete or truncated.

Large post-quantum DNSSEC responses would normally be truncated and retried over TCP. This matters because recursive resolvers commonly request DNSSEC records even when the end client does not need to see them. The DNSSEC OK, or DO, bit tells a resolver that DNSSEC records such as RRSIG, DNSKEY and DS may be included. It does not request validation itself.

A DNSSEC-aware recursive resolver may set DO when querying an authoritative server, then remove the DNSSEC records before returning the answer to a client that did not request them. This lets the resolver cache one DNSSEC-enabled result and avoid a second lookup. The Checking Disabled, or CD, bit tells a recursive resolver not to block or strip data when validation fails. The Authenticated Data, or AD, bit in a response indicates that the resolver has verified the records with DNSSEC. A stub resolver should trust AD only through a secure, trusted and authenticated connection to that resolver.

APNIC Labs found DO set in 60.2% of 36,324,963,331 queries during the week ending 3 November 2026. The same ratio applied to A-record queries, while removing duplicate queries produced a 60.9% ratio. The measurements came from a broad sample of end users reached through Google’s advertising delivery system and the APNIC Labs platform.

During the same period, 40% of users were behind recursive resolvers that performed DNSSEC validation. Another 8.5% were behind systems that attempted validation but retried through a non-validating resolver after SERVFAIL. That suggests 48% of users were sending queries to security-aware resolvers expected to set DO upstream. The additional 12% appeared not to validate DNSSEC, with no DNSKEY queries, although their resolvers still set DO.

The practical impact is limited today by caching and by the fact that only about 2% of queried names are DNSSEC-signed, according to data from Cloudflare’s 1.1.1.1 recursive resolver. APNIC’s measurements deliberately used unique labels, preventing caches from absorbing the queries before they reached authoritative servers. Most stub resolvers also rely on recursive resolvers for validation and use AD as their signal.

If the entire DNSSEC space eventually moved to PQC, APNIC notes that roughly 60% of today’s queries could initially be redirected from UDP to TCP. That raises the question of whether queries carrying DO should go directly to TCP instead. A working Internet draft titled “No DO for you” proposes that non-validating resolvers clear DO, then cache whether a response was obtained with the bit set. If a later client requests DNSSEC records, the resolver would perform a new lookup with DO set.