ICANN's CTO says DNS quantum work is speeding up; the DNSSEC risk is forgery, and an ML-DSA-44 signature is 2,420 bytes

One signature is 1.96 times the packet budget, and the root zone lists no post quantum key

One signature made with ML-DSA-44, the post quantum algorithm that IANA numbered 18 for DNSSEC with a record dated 10 August 2026, is 2,420 bytes (FIPS 204). The DNS Flag Day 2020 default for a UDP message is 1,232 bytes. The signature alone is therefore 1.96 times the whole budget (derived: 2,420 divided by 1,232), before the record it signs, the names or the headers. Separately, the root zone file that internic.net served on 26 October 2026, serial 2026102600, holds 1,516 DS records covering 1,351 of its 1,437 delegated top level domains, and none of them uses algorithm 18 or any other post quantum algorithm (derived by counting).

Those two facts frame what The Register reported at 04:08 GMT on 26 October 2026 under the headline "Work to protect DNS from quantum decryption attacks is speeding up". ICANN's chief technology officer told the reporter at the ICANN87 meeting in Bali that he is aware of efforts at ICANN and other governance bodies to consider what happens once quantum computers arrive, and that the work will speed up: "We're going to ramp up the speed of development". Work is moving on a dated record: a paper in May, an IANA algorithm number in August, a public resolver validating the new algorithm in September, drafts revised in October. What the record does not show is anything protecting a zone in production.

What these facts do not establish: when, or whether, a quantum computer able to break today's DNSSEC keys will exist; that any zone relies on a post quantum signature in production; or that "decryption" in the headline describes the DNSSEC threat. DNSSEC encrypts nothing. Every DNSSEC source below describes the risk as forgery. The article was read in full at 09:39 GMT and its body compared again at 09:58 and 10:05 GMT; it had not changed. All other sources were read between 09:39 and 10:08 GMT on Monday 26 October 2026.

What The Register reported, what the record adds, and what neither states

The article is short and rests on one interview. It names no draft, no algorithm and no date. The table sets each of its claims against the primary record. ICANN's interest: its own press release says it manages the root zone through its IANA functions, so how prepared the root looks reflects on it.

The "larger keys" sentence is the one a reader could misread. It sounds as if today's RSA and elliptic curve keys only need to grow. ICANN's paper says that does not work, because a computer able to break today's key sizes could break a few times larger ones. The fix is to change algorithm, and the new algorithms are the large ones.

Two threats share one headline, and DNSSEC faces only one of them

"Quantum decryption attack" is a friendly name that fits one DNS threat and not the one the article's own body is about. The article's opening speaks of quantum computers that can "challenge conventional encryption" and of "deciphering encrypted information"; its third paragraph names DNSSEC, which signs records and encrypts none.

The confidentiality side is further along. RFC 10024 (August 2026) standardises X25519MLKEM768 for TLS 1.3, value 4588 (0x11EC), with a client share of 1,216 bytes (1,184 for ML-KEM-768 and 32 for X25519). Cloudflare's tracker of third party software, last updated 24 June 2026, lists default hybrid support in Chrome and Edge 131 and later, Firefox 132 and later on desktop, Safari 26 and OpenSSL 3.5. Cloudflare says that in July 2026 most of the traffic it handles already used ML-KEM; that is one operator's own traffic, and a key exchange, not authentication. For the same split applied to TLS, see the earlier briefing on the NCSC TLS guidance.

This site also checked the encrypted endpoints of four widely used public resolvers once, because no primary read says what they negotiate. Between 09:48 and 09:50 GMT on 26 October 2026, repeated for Quad9 and OpenDNS at 10:02, from one network, with a current OpenSSL client, one TLS 1.3 handshake per endpoint (derived, not a primary): Cloudflare (DoH on port 443, DoT on 853) and Google (DoH, DoT) negotiated X25519MLKEM768. Quad9 (DoH, DoT) and Cisco's OpenDNS (DoH) negotiated plain X25519 and refused a hybrid only offer. The server certificates in all of those handshakes used classical signatures (ECDSA P-256 or RSA PSS). That is a single observation. It does not show what any operator plans, what other nodes or other networks do, or what your clients offer.

The size problem, computed from the standards

DNS over UDP has a fixed budget. The DNS Flag Day 2020 page sets 1,232 bytes as the default EDNS buffer size: 1,280, the IPv6 minimum MTU, less 48 bytes of IPv6 and UDP headers (derived: 40 plus 8). RFC 9715 (January 2025) recommends at most 1,400. A response that does not fit is truncated and the resolver must retry over TCP. The table uses the sizes the standards print and shows each signature against that budget.

Three further sums, all derived. Two Falcon-512 signatures come to 1,332 bytes, already over 1,232. An ML-DSA-44 public key is 1,312 bytes, over the limit on its own. A DNSKEY set with one ML-DSA-44 key signing key, one ML-DSA-44 zone key and a single signature is 5,044 bytes of key and signature material, 4.09 times the budget, and Cloudflare notes that zones must keep conventional keys and signatures for older validators for years, which adds to it. An ICANN staff draft (draft-hoffman-pq-dnssec-considerations-02, 2 October 2026) sorts signatures into Tiny (under 400 bytes), Small (400 to 1,400), Large (1,400 to 3,000, which "forces TCP") and Jumbo (over 3,000). On that scale ML-DSA-44 is Large, ML-DSA-65 and SLH-DSA are Jumbo, and Falcon-512 is Small.

The measured evidence is thin and mostly simulated. Cloudflare's printout for a test name signed with ML-DSA-44 shows a truncated UDP reply retried over TCP and "Received 2563 B", 2.08 times 1,232 (derived). SIDN Labs replayed one hour of real traffic to a .nl name server against NSD, Knot, BIND and PowerDNS, making a chosen share of queries retry over TCP: CPU time rose steadily with the share, memory did not change, and sending everything over TCP first became cheaper at 50 per cent retries for BIND, 70 for NSD and PowerDNS, and 90 for Knot. It is a simulation of retries, not of post quantum responses, and it covers the authoritative side only. The Verisign Labs method that signs a Merkle tree ladder is designed to shrink most signatures, but its own draft says "Full MTL-Type responses in this draft will always exceed DNS over UDP" and that at least one full ML-DSA signature is needed. Another route, in an individual draft of 3 July 2026, keeps the large algorithm for the key signing key only and uses a small signature algorithm for the zone key; it needs the rule that a zone be signed with every algorithm in its DNSKEY set relaxed.

What exists today, dated

The deployment record is short enough to list. Several companies named here have a stake. Cloudflare runs the resolver, sells DNS, registrar and security services, and its staff wrote the ML-DSA draft with a Google author, so it has a commercial interest in how fast the work moves. Verisign's research arm wrote the Merkle tree ladder drafts and says it licenses the method royalty free. ICANN is described above. NIST and the standards documents have no product to sell.

Zoom

Friendly names, audited

A label can do the work of a control. Five appear in this story.

Whose clock is it? The dates the sources print

Every date below is one body's own view, and none is a forecast this site endorses. Years from 26 October 2026 are derived.

Two sums show the gap. The root's own key rollover, same algorithm and a new key, began a phased timeline in 2024 and ends in 2027 (ICANN, 20 May 2026): three years for one classical key. And if a new DNSSEC algorithm took ten years to be widely adopted, as SIDN Labs says experience with an earlier rollover shows, adoption begun in 2026 would end in 2036, after NIST's draft disallow date of 2035 (derived, an illustration and not a forecast).

Technical details

These are the artifacts the primary sources print. Each block names its source and the date read; text is copied exactly unless the caption says a part was omitted. Blocks marked derived were produced by this site. None is an attack step.

The IANA registry rows for the algorithm numbers a defender most often meets (8, 13, 14, 15 and 16), and for 18. The third field of a DNSKEY record and the second field of a DS record carry this number. A zone signed only with algorithm 8 or 13 depends on a quantum vulnerable signature.

8,RSA/SHA-256,RSASHA256,Y,*,RECOMMENDED,RECOMMENDED,MUST,MUST,[RFC 5702]; [proposed standard]
13,ECDSA Curve P-256 with SHA-256,ECDSAP256SHA256,Y,*,RECOMMENDED,RECOMMENDED,MUST,MUST,[RFC 6605]; [proposed standard]
14,ECDSA Curve P-384 with SHA-384,ECDSAP384SHA384,Y,*,MAY,RECOMMENDED,MAY,RECOMMENDED,[RFC 6605]; [proposed standard]
15,Ed25519,ED25519,Y,*,RECOMMENDED,RECOMMENDED,RECOMMENDED,RECOMMENDED,[RFC 8080]; [proposed standard]
16,Ed448,ED448,Y,*,MAY,RECOMMENDED,MAY,RECOMMENDED,[RFC 8080]; [proposed standard]
18,ML-DSA-44,MLDSA44,Y,*,MAY,MAY,MAY,MAY,[draft-westerbaan-dnssec-mldsa-03]; [informational]

How the new algorithm looks in a zone. The draft's own example shows a DNSKEY, its DS and an RRSIG with algorithm 18. The key and signature text is long base64 and is omitted here; this site decoded the draft's two values and found 1,312 and 2,420 bytes, matching FIPS 204 (derived).

example.com. 3600 IN DNSKEY 257 3 18 (
             [1312 octet public key, base64, omitted]

example.com. 3600 IN DS 59829 18 2 (
             812cb1a22af04380e2f72d91c06c14eb1a918cf30037a8a9c67497e9264b
             4bfa )

example.com. 3600 IN RRSIG MX 18 2 3600 (
             1440021600 1438207200 59829 example.com.
             [2420 octet signature, base64, omitted]

What a post quantum answer does on the wire. Cloudflare's post prints a query to its resolver for a test name. The reply was truncated over UDP and retried over TCP, arrived with the AD flag set (the resolver validated it), and was 2,563 bytes. The signature text is omitted; the printed value decodes to 2,420 bytes (derived).

$ dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssec

;; WARNING: truncated reply from 1.1.1.1@53(UDP), retrying over TCP

;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 17546
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 3; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; valid.mldsa44.dnstest.dev. IN A

;; ANSWER SECTION:
valid.mldsa44.dnstest.dev. 0 IN A 188.114.97.0
valid.mldsa44.dnstest.dev. 0 IN A 188.114.96.0
valid.mldsa44.dnstest.dev. 0 IN RRSIG A 18 4 0 20260910114537 20260909104537 23176 valid.mldsa44.dnstest.dev. [signature omitted]

;; Received 2563 B
;; From 1.1.1.1@53(TCP) in 20.7 ms

Cloudflare's test page for a resolver's post quantum readiness prints five commands, one per test zone. The page explains the expected result of each: the first needs algorithm 18 support, the second should be blocked by a resolver that validates it, the third (valid P-256, broken ML-DSA-44) should be blocked only by a resolver with downgrade protection, the fourth should resolve, and the fifth is a control that every validating resolver blocks. To test your own resolver, replace 1.1.1.1 with its address (this site's instruction; the page prints 1.1.1.1). Use a staging resolver, not production.

dig @1.1.1.1 valid.mldsa44.dnstest.dev A +dnssec
dig @1.1.1.1 invalid.mldsa44.dnstest.dev A +dnssec
dig @1.1.1.1 downgrade.mldsa44.dnstest.dev A +dnssec
dig @1.1.1.1 upgrade.mldsa44.dnstest.dev A +dnssec
dig @1.1.1.1 invalid.alg13.dnstest.dev A +dnssec

Whether truncation and TCP work is the first thing a larger signature breaks. The DNS Flag Day 2020 page prints the checks and the 1,232 byte settings for common software. Both commands should return the same answers with and without +tcp. The page notes the settings will have no visible effect if everything works, and that some queries fail to resolve if TCP is not available.

$ dig +tcp @auth_IP yourdomain.example.
$ dig +tcp @resolver_IP yourdomain.example.
$ dig @resolver_IP test.knot-resolver.cz. TXT

BIND
options {
  edns-udp-size 1232;
  max-udp-size 1232;
};

Knot DNS
server:
  max-udp-payload: 1232

Knot Resolver
net.bufsize(1232)

PowerDNS Authoritative
udp-truncation-threshold=1232

PowerDNS Recursor
edns-outgoing-bufsize=1232
udp-truncation-threshold=1232

Unbound
server:
  edns-buffer-size: 1232

NSD
server:
  ipv4-edns-size: 1232
  ipv6-edns-size: 1232

To see which algorithm a zone uses and what size its key response is. This block is derived by this site, not copied from a primary: the field positions come from the records in the draft example above, where a DNSKEY reads flags, protocol, algorithm and a DS reads key tag, algorithm, digest type. Replace example.com with your zone.

dig +dnssec DNSKEY example.com
dig DS example.com
dig +bufsize=1232 +dnssec DNSKEY example.com
dig +tcp +dnssec DNSKEY example.com

The key exchange side. IANA's TLS group registry and RFC 10024 give the identifier of the hybrid group a DoT, DoH or DoQ client and server must both offer to use it. Cloudflare's browser check on Radar tests a browser; no primary read prints a command for testing a resolver's TLS endpoint, so none is given here.

4588,X25519MLKEM768,Y,Y,[RFC 10024],Combining X25519 ECDH with ML-KEM-768

Value: 4588 (0x11EC)
Description: X25519MLKEM768
DTLS-OK: Y
Recommended: Y
Reference: RFC 10024
Comment: Combining X25519 ECDH with ML-KEM-768

The size of the client share is 1216 bytes (1184 bytes for the ML-KEM part and 32 bytes for X25519).

The root's trust anchors as IANA publishes them: both current root key signing keys use algorithm 8. These are public key digests, not secrets.

<KeyDigest id="Klajeyz" validFrom="2017-02-02T00:00:00+00:00">
    <KeyTag>20326</KeyTag>
    <Algorithm>8</Algorithm>
    <DigestType>2</DigestType>
<KeyDigest id="Kmyv6jo" validFrom="2024-07-18T00:00:00+00:00">
    <KeyTag>38696</KeyTag>
    <Algorithm>8</Algorithm>
    <DigestType>2</DigestType>

This site's count of DS records in the root zone by algorithm. The script is calc.py and reads the file internic.net/domain/root.zone, whose SOA serial was 2026102600 when read. Every TLD that has a DS record has records of one algorithm only.

DS records by algorithm (total 1516)
  8  RSA/SHA-256          1185  (78.2%)  1043 TLDs
  13 ECDSA P-256           291  (19.2%)   273 TLDs
  10 RSA/SHA-512            29   (1.9%)    28 TLDs
  7  RSASHA1-NSEC3-SHA1      7   (0.5%)     3 TLDs
  15 Ed25519                 3   (0.2%)     3 TLDs
  14 ECDSA P-384             1   (0.1%)     1 TLD
  18 ML-DSA-44               0   (0.0%)     0 TLDs
1351 of 1437 delegated names have a DS record

How a resolver can tell a user that a local post quantum policy rejected an answer. The Cloudflare author's draft of 6 August 2026 suggests an Extended DNS Error 6 (DNSSEC Bogus) whose extra text points to the policy, so that the refusal is not mistaken for filtering. It is an example in a draft, not a deployed convention.

{
  "fbds": [
    {
      "db": "resolver-operator-reference",
      "id": "quantum-safe-validation-policy"
    }
  ]
}

Two software notes from the informal community list on GitHub (unverified by this site): Loop 1.99.22 and above enable post quantum downgrade protection by default, with a view level option named dnssec-pq-lenient-validation; and the list says PowerDNS Recursor support is on master and expected in 5.5.0.

A ranked checklist for registrars, resolver operators and enterprises

Ordered by what is useful before any post quantum zone exists. The first three need no new software.

The question the headline does not ask

The headline says work is speeding up. The record shows one named public resolver, one algorithm number, at least ten individual drafts and no registry record, no root key and no production zone named. It also shows why: every link depends on the one above it, and Cloudflare's own warning is that an attacker who recovers a root key could forge a path to any zone below it, "break once, forge everywhere". Those links belong to different organisations, each of which can reasonably wait for the others to move first.

So the question for a security lead is not whether quantum computers will arrive in three years, five or ten. It is which link in your own chain of trust nobody in your organisation can change, and who owns the date on which your zone stops relying on a signature that a quantum computer could forge.

Key facts