Is your DNS resolver post-quantum ready?
ML-DSA-44 is a post-quantum signature algorithm standardized by the US National Institute of Standards and Technology and assigned algorithm 18 for use with DNSSEC. Unlike today's RSA and ECDSA signatures, it is designed to remain secure against future quantum computers. Its 2,420-byte signatures and migration alongside existing algorithms introduce new transport and downgrade-protection challenges.
This test requests five zones with different combinations of ML-DSA-44 and P-256 signatures. Their reachability indicates whether your current resolver validates DNSSEC, supports algorithm 18, and protects against downgrade attacks.
Learn more about post-quantum DNSSEC, read the ML-DSA for DNSSEC Internet-Draft, or follow the community's ML-DSA-44 software support tracker on GitHub.
| Zone and setup | Result |
|---|---|
PQ onlyValid ML-DSA-44 signatures; no P-256The parent publishes only an algorithm 18 DS record and the child is signed only with ML-DSA-44. A resolver with algorithm 18 support can follow the chain and validate the answer as secure. A resolver that does not recognize algorithm 18 has no supported DS record and should treat the delegation as insecure, not bogus. Expected: Secure when algorithm 18 is supported; otherwise treated as either insecure or blocked. | waiting |
dualValid ML-DSA-44 and P-256 signaturesThe parent publishes DS records for algorithms 18 and 13. The child publishes both keys and valid signatures from both. New resolvers can validate ML-DSA-44 while older resolvers retain a valid P-256 path. Expected: Reachable for every resolver. If this zone is blocked, the test cannot reliably classify the other results. | waiting |
downgradeInvalid ML-DSA-44 signatures; valid P-256Both algorithms are registered in the parent, but the ML-DSA-44 validation path is broken while the P-256 path remains valid. RFC 6840 normally permits a validator to accept any single valid path. Cloudflare applies a stricter local policy: when an authenticated DS RRset contains a supported post-quantum algorithm, a valid post-quantum path is required. Expected: Blocked by resolvers with ML-DSA-44 downgrade protection. A resolver following only the conventional any-valid-path rule may still accept it through P-256. | waiting |
upgradeValid ML-DSA-44 signatures; invalid P-256Both algorithms are registered, but only the ML-DSA-44 validation path works. A resolver with algorithm 18 support can authenticate the answer despite the broken P-256 signatures. A validating resolver that understands only P-256 has no valid supported path. Expected: Reachable through resolvers with algorithm 18 support; blocked by validating resolvers without algorithm 18 support. | waiting |
non-PQ invalidInvalid P-256 signatures; no ML-DSA-44The parent delegates through the conventional algorithm 13 path, but the child's P-256 signatures are deliberately invalid. There is no ML-DSA-44 path to fall back to. This separates DNSSEC validation behavior from algorithm 18 support. Expected: Blocked by every DNSSEC-validating resolver. If it is reachable, the browser's resolver is probably not validating DNSSEC. | waiting |
How to read this test
- Green means the result matches a post-quantum-ready resolver; red means it does not. A blocked result can be correct for a deliberately invalid zone, while a reachable result can reveal missing validation or downgrade protection.
- The browser uses its currently configured resolver. Browser secure DNS, a VPN, or operating-system settings may affect which resolver is tested.
- Running the test contacts five HTTPS hosts under
dnstest.dev. Running it again may reuse DNS cache entries, so it does not guarantee a fresh resolver lookup. - An ML-DSA-44 signature is larger than common DNS-over-UDP limits. A truncated UDP response followed by a TCP retry is expected.
- In the command-line results, the
ADflag means the resolver validated the answer as secure. The ML-DSA-44-only zone can still resolve withoutADwhen algorithm 18 is unsupported.