Short version: you don't need to do anything urgent today, and your small site is not about to break because of quantum computers. The switch to post-quantum cryptography is happening at the layer your host and browser handle for you — your job is to pick providers who are on it, and to know how to read the new DNSSEC error codes when something goes wrong.
Cloudflare recently made two moves worth paying attention to. They argued for adopting ML-DSA (a post-quantum signature standard) sooner rather than later, and after a top-level domain outage they shipped new DNSSEC error codes so operators can actually see what failed. Both are plumbing changes — the quiet kind that can take a site offline without warning. So it's worth understanding what's yours to worry about and what isn't.
Here's the honest framing: the encryption keeping your traffic private today is fine for today. The concern is "harvest now, decrypt later" — someone storing encrypted traffic in the hope of cracking it once quantum computers mature. That matters for long-lived secrets, less so for a brochure site or a small shop.
What ML-DSA actually is (and why now)
ML-DSA is a quantum-resistant digital signature algorithm, standardised by NIST as FIPS 204, and it's starting to replace the RSA and ECDSA signatures we use for TLS certificates and DNSSEC. It proves "this message really came from who it claims" in a way a future quantum computer can't forge.
There are two separate quantum problems, and people muddle them constantly:
- Key exchange (agreeing on a session secret) is the "harvest now, decrypt later" risk. This is already being fixed — Chrome, Firefox and most big servers now negotiate a hybrid post-quantum key exchange (X25519 + ML-KEM) automatically.
- Signatures (proving identity) can't be harvested. A forged signature is only useful in real time, so there's no rush from a secrecy angle — the pressure is that certificates and DNS chains take years to migrate, so the industry wants to start early.
Cloudflare's "ML-DSA will have to do" point is pragmatic: the post-quantum signature options are all a bit clunky (big signatures, more bytes on the wire), ML-DSA is the least bad and it's ready, so let's not wait for something perfect. That's the right call. For you, it means larger TLS handshakes and larger DNSSEC responses over the next few years — handled by your providers, not by you.
Your actual to-do list
For a small site, the whole job is choosing providers who are already moving and confirming a couple of settings — there's nothing to hand-code.
- Keep TLS current. Make sure your site serves TLS 1.3. If you're on shared hosting or a managed platform, this is already done. The post-quantum key exchange rides on top of it automatically once your host enables it.
- Don't pin certificates or algorithms. If you have any old HPKP headers or hardcoded certificate fingerprints in an app, remove them. Pinning is what breaks when the crypto underneath changes.
- Check whether DNSSEC is on — and monitored. DNSSEC is great when it works and a full outage when it doesn't. Only run it if your DNS provider signs and rotates keys for you and alerts you on failures.
- Confirm your registrar supports modern DS records. When DNSSEC keys change, the DS record at your registrar must update too. A registrar that lets you manage this cleanly (or does it automatically via CDS/CDNSKEY) saves you a 3am incident.
- Watch handshake sizes if you tuned anything. Post-quantum handshakes are bigger. If you ever set a tiny MTU or aggressive buffer limits on a proxy, loosen them.
That's it. No key generation, no algorithm selection, no maths. If your provider is doing their part, this is a background upgrade.
How CDS/CDNSKEY automation actually saves you
The manual DNSSEC dance is the dangerous bit: you roll a new key in your zone, then you have to log into the registrar and paste a fresh DS record before validators start rejecting the old one. Miss the window and your domain goes dark. CDS and CDNSKEY records automate that handoff. Your DNS provider publishes a signed CDS (or CDNSKEY) record inside the zone describing the DS record it wants at the parent. The registry polls for it, verifies the signature against the currently trusted key, and updates the DS record for you — no copy-paste, no 3am login. If your DNS host and your registry both speak RFC 7344/8078, key rollovers become genuinely hands-off. Before you enable DNSSEC anywhere, ask both providers one question: do you support CDS/CDNSKEY? If either says no, you're back to manual DS updates and the outage risk that comes with them.
How to read the new DNSSEC error codes
DNSSEC failures used to return a bare SERVFAIL, which told you nothing — the new Extended DNS Errors (EDE) codes tell you why validation failed, so you can fix the right thing. These arrived after real outages where operators were left guessing.
The ones you'll actually see:
| Code | Meaning | Usual cause |
|---|---|---|
| EDE 6 | DNSSEC Bogus | Signatures don't validate — often a broken key rotation |
| EDE 7 | Signature Expired | RRSIG lapsed; automated re-signing failed |
| EDE 8 | Signature Not Yet Valid | Clock skew on the signer |
| EDE 9 | DNSKEY Missing | Key referenced by DS record isn't published |
| EDE 10 | RRSIGs Missing | Zone claims to be signed but records aren't |
| EDE 5 | DNSSEC Indeterminate | Broken chain of trust up the delegation |
You can pull these yourself with dig. Run dig +dnssec example.com and check the header flags: a healthy validated answer shows the ad (Authenticated Data) flag set. If ad is missing and you get a SERVFAIL, validation failed somewhere. Query a validating resolver to see the extended error — for example dig @1.1.1.1 example.com +dnssec. If that returns SERVFAIL, don't stop there: re-run with dig @1.1.1.1 example.com +dnssec +cd to bypass validation (the +cd, Checking Disabled, flag). If the answer suddenly resolves with +cd but fails without it, you've confirmed the problem is a DNSSEC validation failure rather than the record simply not existing. A recent dig against a resolver that returns EDE will print the reason inline, like this:
;; OPT PSEUDOSECTION:
; EDE: 9 (DNSKEY Missing): (no matching DNSKEY found)
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
That single line tells you the DS record at the parent points at a key the zone no longer publishes — a stale DS after a rollover. For a visual view of the whole chain, use a tool like DNSViz (a community/Sandia project, not Verisign's) or Verisign's own DNSSEC Analyzer as a second opinion. Either one spots a mismatched DS record in seconds without you reading raw records.
The most common real-world failure is exactly that EDE 9 stale DS record: you rotated your DNSSEC key but the DS record at the registrar still points at the old one. The chain breaks and your whole domain goes dark for validating resolvers — which now includes a big chunk of the internet.
Why you don't need to panic
No production quantum computer can break today's encryption, and the migration is being done by browsers, servers and resolvers on a multi-year timeline — your existing certificates and DNS keep working the entire time. There is no deadline where your small site suddenly stops.
The genuine near-term risk isn't quantum at all — it's DNSSEC misconfiguration. Every year a few big domains take themselves offline with an expired signature or a botched key rollover. If you turn DNSSEC on without automation and monitoring, you've added a new way to fail for a threat model most small sites don't face. Turn it on only if it's managed for you.
Put your energy where the payoff is real:
- Get on TLS 1.3 and let post-quantum key exchange happen automatically.
- Remove any certificate or key pinning.
- Only enable DNSSEC with a provider who automates signing, rotation and DS updates.
- Bookmark a DNSSEC checker so you can read an EDE code in 30 seconds when it matters.
Where TPC fits in
The reason this stuff is safe to ignore day-to-day is that your host and registrar carry it — so the sensible move is picking ones who take it seriously. At TPC Hosting we keep TLS configurations current across our servers, so the post-quantum handshake gets enabled as the software supports it, without you touching a config file.
We're EU-hosted and GDPR-friendly, and there are real engineers on support 24/7 — so if you hit a SERVFAIL and a cryptic EDE code at an awful hour, there's a human who can read the chain with you instead of a ticket queue. If you're moving from another host, migration is free and you've got 30 days to back out if it's not right.
Post-quantum crypto is one of those transitions that should be invisible when it's done well. Line up the two or three settings above, choose providers who are already moving, and you can get back to running your actual site.
Want a host that handles this behind the scenes so you don't have to? Take a look at tpc-hosting.com.
FAQ
Do I need to change my SSL certificate for post-quantum security?
No — not right now. Your current TLS certificate keeps working, and the post-quantum protection that matters most (key exchange) is added automatically by browsers and servers on top of your existing setup. Certificate signatures will migrate to ML-DSA over the coming years, handled by your certificate authority and host.
Should a small business turn on DNSSEC?
Only if your DNS provider automates signing, key rotation and DS record updates and alerts you on failure. DNSSEC done manually is a common cause of full-domain outages, and for a typical small site the misconfiguration risk outweighs the benefit unless it's fully managed for you.
What does a SERVFAIL with an EDE code actually mean?
SERVFAIL means a resolver refused the answer, and the Extended DNS Error (EDE) code tells you why. EDE 6 means signatures didn't validate, EDE 7 means a signature expired, and EDE 9 means a DNSKEY the DS record points to is missing — the last one usually means a stale DS record at your registrar. Re-run the query with +cd to confirm it's a validation failure and not a missing record.
Is 'harvest now, decrypt later' a threat to my website?
It's a low priority for most small sites. The attack targets long-lived secrets captured today and decrypted years later once quantum computers mature, which matters more for banks and governments than for a shop or blog. Enabling TLS 1.3 with post-quantum key exchange closes the gap anyway, at no effort on your part.
What is ML-DSA in plain terms?
ML-DSA is a quantum-resistant digital signature standard (NIST FIPS 204) that proves a message came from who it claims, in a way a future quantum computer can't forge. It's replacing RSA and ECDSA signatures in TLS certificates and DNSSEC gradually, and the change is handled by your providers, not by you.
