Cloudflare’s September 10 engineering report says its 1.1.1.1 resolver now validates DNSSEC signatures made with ML-DSA-44, the NIST-standardized post-quantum digital-signature algorithm. This is a real resolver-side deployment, not an announcement that the entire Domain Name System has become quantum-safe. The interesting operational story is what happens when a new signature meets old packet limits, mixed-algorithm compatibility, and a chain of trust shared by many organizations.
DNSSEC authenticates DNS data; it does not encrypt a user’s browsing. Its quantum risk is therefore about future forgery of signed answers, not an attacker storing today’s DNS traffic for later decryption. No cryptographically relevant quantum computer is known to exist today. Yet DNS changes take time because resolvers, authoritative servers, registrars, registries, and ultimately the root must cooperate. That long coordination path is a reason to test now, without pretending the threat has already arrived.
The signature does not fit the comfortable DNS packet
Cloudflare reports that an ML-DSA-44 signature is 2,420 bytes. Its comparison puts an ECDSA P-256 signature at 64 bytes. A post-quantum signature alone exceeds the conservative 1,232-byte UDP payload many resolvers advertise, and also exceeds the 1,400-byte UDP maximum recommended by RFC 9715. DNS headers, records, names, keys, and sometimes multiple signatures add still more data.
The ordinary response is not to insist that UDP carry the impossible. An authoritative server can truncate its answer, prompting a resolver to retry over TCP. That may work perfectly, but it changes latency, bandwidth, connection volume, and middlebox behavior. DNSKEY responses are especially important because they carry material needed to validate the zone. During a rollover, additional keys can make an already large answer larger.
For an operator, the useful test is not merely “does the signature verify in a library?” It is whether a full response reaches real validators through the network paths customers use, including loss, restrictive firewalls, load balancers, and cross-provider handoffs. Measure TCP fallback rates and errors before declaring a zone migration successful. A green unit test cannot tell you whether a remote resolver times out.
Two signatures can preserve compatibility—and preserve a downgrade path
Existing validators do not all understand ML-DSA-44. A zone may therefore publish conventional and post-quantum signatures together. That keeps older resolvers working, but it raises a harder question for a resolver that understands both: is one valid conventional path enough, or must it validate the post-quantum path?
Cloudflare describes a stricter local policy. When authenticated parent-zone DS records signal a supported post-quantum algorithm, 1.1.1.1 requires a valid post-quantum validation path instead of silently accepting a conventional-only answer. This matters because a future attacker able to forge a classical signature could otherwise present a plausible-looking downgrade. The parent signal must itself be protected through the delegation chain. A post-quantum-signed child is not end-to-end quantum-safe if an ancestor remains a weak point.
That distinction is easy to miss in procurement language. “Supports ML-DSA” can describe a resolver, a signing service, a registrar workflow, or a zone. None alone proves the whole chain. Cloudflare explicitly describes its current work as resolver-side; authoritative signing and registrar support are next steps, and a complete post-quantum path to the root has not been established.
What DNS and security teams should do now
- Map the signing chain. Record each critical zone, its signing algorithms, authoritative provider, registrar, registry, resolver population, DS records, and trust anchors. Include delegated subdomains and third-party DNS services.
- Separate capability from deployment. Note which components can validate, which can sign, and which actually do so. Keep experimental zones distinct from production promises.
- Test the transport. Exercise DNSKEY and ordinary signed answers across UDP truncation, TCP retry, constrained networks, and rollover conditions. Record failure rates and affected client groups.
- Define downgrade policy. Ask how each validator treats a mixed classical/PQC zone and what authenticated signal triggers a post-quantum requirement.
- Prepare reversible change. Plan key rollover, monitoring, escalation, and rollback with registrars and providers before changing a high-value zone.
The practical sequence is discovery, dependency mapping, controlled experiments, and evidence review—not a single switch labeled “quantum-safe.” DNS is a good illustration of why cryptographic migration must be governed as a system change.
Where Vista Platform fits
Vista Platform is a self-hosted cryptographic system of record. Its operating loop is discovery, canonical inventory, evaluation, action, and proof. It can help teams organize observed algorithms, certificates, assets, owners, dependencies, assessments, and remediation evidence around a DNSSEC migration. Vista Core is source-available and includes discovery, inventory, compliance/PQC assessment, and CBOM generation without asset, sensor, seat, or time caps.
Vista tracks and governs post-quantum migration; it does not sign DNS zones, generate PQC keys, or perform every migration step. Selected-asset Active Scan is not indiscriminate network scanning. Vista is not a vulnerability scanner, and a discovery gap is not proof that a zone or dependency is absent. See Vista’s post-quantum approach.
What remains uncertain
Cloudflare’s report is an operator account of its own deployment, not a measurement of all resolvers or registries. The real-world cost of larger DNSSEC responses, the pace of authoritative and registrar support, and the path to a post-quantum root anchor remain unsettled. Teams should use the experiment to sharpen test plans, not infer universal readiness.
Sources
- 1.1.1.1 now supports post-quantum DNSSEC, all 2,420 bytes of it, Cloudflare, September 10, 2026.
- RFC 9715: DNS Transport over TCP—Operational Requirements, RFC Editor, March 2025.