Post-Quantum DNSSEC Can't Protect You Yet. Here's Why

Earlier this month, Cloudflare announced that its 1.1.1.1 resolver can now validate post-quantum DNSSEC signatures. Since then, a few of you have asked us whether Control D does the same.

The short answer is no, it doesn't yet. Control D validates DNSSEC today, including on our free resolvers, but it doesn't support the new post-quantum algorithm. 

We've been following this closely, and we believe that's the right call for now, since a lot of things still have to change before post-quantum DNSSEC can protect anyone. Here's our thinking.

What Cloudflare Actually Changed

How DNSSEC Works

DNSSEC lets a resolver validate that a DNS answer is really what the domain's owner intended. Domain owners sign their records, and each zone's parent vouches for the keys behind those signatures. The root zone vouches for .com, for example, and .com vouches for controld.com.

If a signature doesn't check out, a validating resolver refuses the answer instead of sending you to a possibly forged address.

Why Quantum Computers Are a Problem

Today's signatures use algorithms like RSA and ECDSA. A large enough quantum computer is expected to be able to break these algorithms to discover keys, and use those keys to forge signatures that would look valid to every resolver that checks them. That would let an attacker send you to a fake website, such as a lookalike login page, without anything looking wrong because the check designed to catch it would come back clean.

Nobody has built a machine like that yet, and nobody knows when someone will, but Cloudflare is planning for it to happen as early as 2030. Even if that’s true, moving all of DNS to new algorithms takes years, so the work has to start now.

What 1.1.1.1 Can Do Now

1.1.1.1 can now check signatures made with ML-DSA-44, a post-quantum algorithm standardized by NIST. In DNSSEC, it's known as algorithm 18.

These new signatures are much larger. An ML-DSA-44 signature is about 2,420 bytes, compared with 64 bytes for the ECDSA signatures most domains use today. That matters because DNS data efficiency is important, but also because attackers use the difference between the size of a query and the size of a response in reflection attacks.

Why Post-Quantum DNSSEC Can’t Protect You Yet

Checking the new signatures is only the first step. Several other things have to happen before post-quantum DNSSEC protects anyone, and some of them will take years.

The Root Isn't Post-Quantum Yet

DNSSEC is only as strong as the chain above a domain. The root zone has been signed with RSA since 2010, and it vouches for every top-level domain on the internet. If an attacker could forge the root's signature, they could fake anything below it, which is why attackers aim as high up the chain as they can.

Until the root and the top-level domains switch to post-quantum signatures, signing your own domain with one won't protect you from a quantum attacker.

Why Old Signatures Are Still a Risk

The move to new signatures won't happen overnight. For years, domains will carry both old and new signatures so that older resolvers keep working. Under today's rules, a resolver accepts an answer if any one of its signatures is valid. Once the old signatures can be forged, an attacker can send a forged old signature and simply leave out the new one.

Cloudflare has enabled post-quantum validation as a valuable operational exercise, but it can’t reject valid ECDSA or RSA signatures according to the DNSSEC protocol. A broken root or TLD key can result in forged responses that don’t even have the ML-DSA signatures. 

A domain can only be protected by post-quantum signatures if the parent's own record is protected by post-quantum signatures, all the way up to the root. 

A user (like Control D’s customers) can only be assured that they are protected from quantum attacks when the older algorithms are retired. Until then, the new algorithm is useful for testing, but it doesn't make anyone safer.

The Standard Is Still a Draft

The ML-DSA standard for DNSSEC is still an Internet-Draft, so it will probably change before it's widely used. DNSSEC itself went through the same thing when it first rolled out.

The larger signatures also mean real work for the people running DNS. When an answer is too big for one message, the resolver has to ask again over TCP, a slower connection that's harder to run at scale. Authoritative servers, the ones that hold each domain's official records, will need to handle far more of these TCP connections. Resolvers will need to keep up as domains switch algorithms, on whatever schedule those domains choose.

Where Control D Stands

Cloudflare published a set of test domains that show how any resolver handles post-quantum DNSSEC. We ran them against Control D.

Regular DNSSEC Validation

For regular DNSSEC, Control D works as it should, including on our free resolvers. Domains with deliberately broken signatures fail to resolve, and correctly signed domains come back marked as verified.

Post-Quantum Signatures

The post-quantum test domains resolve normally through Control D, but they aren't marked as verified. That includes the ones Cloudflare deliberately broke. This is standard behavior. When a resolver doesn't support a signature algorithm yet, the rules tell it to treat the domain as unsigned rather than block it.

Nothing breaks for Control D users, but it does mean domains signed only with ML-DSA-44 don't get DNSSEC protection from us yet. All the other resolvers we tested work the same way, as expected, and 1.1.1.1 is the exception.

What We're Watching

Three developments matter most to us here:

• The root and major top-level domains moving to post-quantum signatures
• The ML-DSA standard being finalized, since it's still a draft today
• Classic algorithms being retired, so post-quantum signatures are the only ones accepted

Those are the points where supporting the new algorithm starts to make people safer. We'll revisit this as those milestones happen and add support once post-quantum DNSSEC has been shown to work better, not worse, and there's solid operational experience out there.

Try It Yourself

The domain invalid.mldsa44.dnstest.dev has a deliberately broken post-quantum signature. A resolver that validates ML-DSA-44 will refuse it and return SERVFAIL. A resolver that doesn't will return an address without the ad (authenticated data) flag. You can check any resolver with:

dig @76.76.2.0 invalid.mldsa44.dnstest.dev +dnssec  # Control D
dig @1.1.1.1 invalid.mldsa44.dnstest.dev +dnssec    # Cloudflare

What This Means in Practice

If You Use Control D

You don't need to change anything. DNSSEC validation happens on our resolvers, so when post-quantum signatures are ready to protect real domains, supporting them is our side of the work. You won't need to set anything up.

If You Manage Domains

We'd hold off on signing your domains with ML-DSA-44 for now, even once Cloudflare and other DNS hosts offer it. DNSSEC mistakes tend to be all or nothing. A bad signature can stop your domain from resolving for anyone behind a strict validator, and to your users it will look like your website and email have disappeared.

It's better to wait until the chain above you has caught up and your DNS provider recommends it for production.

If You Want to Experiment

Now is a great time to try it. Sign a test domain or point a few resolvers at Cloudflare's test zones, and see what happens. We're right there with you, and we'd love to hear what you find.

It's Always DNS

Anyone who works with networks knows the joke that when something breaks, “it's always DNS.”

DNS sits underneath almost everything, so when it fails, a lot of other things fail with it, usually in confusing ways.

That's why we're glad Cloudflare is testing this carefully and early. It's also why we're in no rush to switch on something the rest of the chain isn't ready for.

Post-quantum DNSSEC is coming, even if nobody knows exactly when. We'll keep running these tests as support improves, both at Control D and across the internet, and we'll update this post when things change.