On September 10, 2026, Cloudflare announced that 1.1.1.1 now validates post-quantum DNSSEC using ML-DSA-44. This advances DNS authentication; it does not automatically make every domain resistant to quantum computers.
For a website, API or VPS administrator, the distinction matters: resolving an address, authenticating the answer and encrypting the connection are separate jobs. Here is what changes, together with a real DNS query performed by TERAMONT.
What changed, and how far does it reach?
According to Cloudflare's announcement, validation is enabled at the resolver without users having to activate it. Complete protection requires a compatible trust chain up to the root, not merely a signature on the final domain. An ML-DSA-44 signature is 2,420 bytes. Matching authoritative signing and Registrar DS support are described as next steps, not capabilities already deployed by this announcement.
DNSSEC is not encrypted DNS
| Layer | What it provides | What it does not prove |
|---|---|---|
| DNSSEC | Authenticity and integrity of DNS data through signatures. | That queries are concealed or the website is trustworthy. |
| DNS over HTTPS or TLS | Encrypted transport between client and resolver. | That the entire DNSSEC chain is post-quantum. |
| Website HTTPS | Protection for the connection to the web service. | That its domain uses this new DNSSEC algorithm. |
The encrypted DNS documentation covers 1.1.1.1's transport options. These layers complement one another: changing a resolver does not replace your website certificate, software updates or control-panel access policies.
Generated illustration of trust between components, not an exact diagram of Cloudflare's network.
Our real test: one query from our environment
On September 11, 2026, at 18:50 UTC−6, we used dig to query the test domain identified by Cloudflare. This only queried public DNS; it did not change a domain or server configuration.
Run your application in an environment you control
Explore TERAMONT VPS Hosting for your project. Security still requires separate configuration and maintenance of the system, application and DNS.
dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssec +noall +comments +stats| Local observation | Result | Interpretation |
|---|---|---|
| Status | NOERROR | The query received an answer without a DNS error. |
| Authentication flag | ad | The resolver reported authenticated data. |
| Final transport | TCP after a truncated response | The tool retried over TCP. |
| Advertised UDP budget | 1,232 bytes | The EDNS value observed in this query. |
| Received size | 2,563 bytes | This response's size, not the size of all DNS queries. |
| Reported query time | 65 ms | A single observation, not a comparative benchmark. |
Test limitations: one query, one environment and one moment. We did not control cache state or compare regions, providers or algorithms. The ad flag alone does not prove an entirely post-quantum chain; our client trusts the resolver's assertion. Those 65 ms cannot establish whether your website will become faster or slower.
How to check your domain without changing it
On a computer with dig, replace the example domain with yours and inspect its ordinary records first. These are read-only checks:
dig @1.1.1.1 example.com A +dnssec
dig @1.1.1.1 example.com DNSKEY +dnssec
dig @1.1.1.1 example.com DS +dnssecReview the response status, signatures, and DNSSEC configuration at your DNS provider and registrar. A missing ad flag is not proof of an attack. Nor does SERVFAIL identify a cause by itself: delegation, signatures and connectivity may need investigation. Consult the official DNSSEC troubleshooting guide before changing records.
What should a VPS administrator do?
- Map responsibilities. Record who registers the domain, who publishes its DNS and where the application runs. They can be three different providers.
- Review existing DNSSEC. The registrar's DS record must correspond to the zone's keys. Follow the provider documentation; never copy keys from an example.
- Keep TCP diagnostics possible. Our query needed that transport. If UDP works but TCP fails in your environment, review the applicable network policy without opening services indiscriminately.
- Prepare recovery. Before switching DNS providers, document records, TTLs and the migration procedure. Do not delete DS records or disable DNSSEC merely because of this announcement.
- Maintain the other layers. System updates, least privilege, HTTPS and backups remain necessary.
If you need infrastructure you can administer for your application, explore TERAMONT VPS Hosting. Purchasing a VPS does not itself enable post-quantum DNSSEC: domain and application configuration remain separate responsibilities.
Verdict: meaningful progress, not universal protection
The announcement matters because it adds validation capability the ecosystem needs. For a production website, the sensible response is to understand its DNS chain, verify it works and avoid rushed changes. Our test adds a concrete observation: this large response resolved through a TCP retry. It does not establish universal adoption or complete protection against every threat.
