dnstest.dev
Home

Is your DNS resolver post-quantum ready?

JavaScript is requiredEnable JavaScript to run this test.

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: valid and invalid ML-DSA-44 cases, upgrade and downgrade scenarios, and an invalid P-256 control. Comparing their results shows 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.

DNS resolver test results
Zone and setupResult
PQ onlyValid ML-DSA-44 signatures; no P-256

The 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: Reachable with algorithm 18 support; it may also resolve as insecure without support.

dig @1.1.1.1 valid.mldsa44.dnstest.dev A +dnssec
waiting
PQ invalidInvalid ML-DSA-44 signatures; no P-256

The parent and child use only algorithm 18, and the child's signature is deliberately invalid. A resolver that validates ML-DSA-44 should block it. Without algorithm 18 support, the parent and its descendants may be treated as insecure, allowing even this invalid answer to resolve.

Expected: Blocked when algorithm 18 validation works; may resolve when the algorithm 18-only parent is treated as insecure.

dig @1.1.1.1 invalid.mldsa44.dnstest.dev A +dnssec
waiting
downgradeInvalid ML-DSA-44 signatures; valid P-256

The child has both algorithms, 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. Without algorithm 18 support for the parent, neither child path is authenticated.

Expected: Blocked with ML-DSA-44 downgrade protection; only meaningful when algorithm 18 validation is established by the valid and invalid PQ zones.

dig @1.1.1.1 downgrade.mldsa44.dnstest.dev A +dnssec
waiting
upgradeValid ML-DSA-44 signatures; invalid P-256

The child has both algorithms, 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 resolver without algorithm 18 support may instead treat the entire subtree as insecure, so reachability here alone does not establish support.

Expected: Reachable through an algorithm 18 validation path; only meaningful when the invalid PQ zone is blocked.

dig @1.1.1.1 upgrade.mldsa44.dnstest.dev A +dnssec
waiting
non-PQ invalidInvalid P-256 signatures; no ML-DSA-44

The 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.

dig @1.1.1.1 invalid.alg13.dnstest.dev A +dnssec
waiting

How to read this test

  • Green means the result matches a post-quantum-ready resolver; red means it does not. Some results stay neutral until algorithm 18 validation can be established. 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.
  • The parent mldsa44.dnstest.dev uses only algorithm 18. A resolver without support may treat it and all its child zones as insecure. Reaching the upgrade or downgrade zone alone does not show which signatures were validated; the valid and invalid ML-DSA-44 results must be considered together.
  • In the command-line results, the AD flag means the resolver validated the answer as secure. A resolver treating the post-quantum subtree as insecure may resolve its names without AD.