‘You are totally compromised!’ because you don’t have DNSSEC configured on domain…..

The implication is that you’re one packet away from catastrophe. It’s alarming. It’s also, for the overwhelming majority of organisations, not true. I have been talking about this for years and years!

Here’s the quickest way to see through it. I scanned the Majestic Million – the top one million domains on the internet – for DNSSEC. About 6.75% were signed (around 8.2% if you only count domains that actually resolve). The .com zone, which is half the list, sits at 4.6%. And the unsigned set includes google.com, amazon.com and microsoft.com.

So if “no DNSSEC” means “totally compromised,” then the three most-attacked, best-defended companies on the planet are totally compromised, and have been for years, on purpose. They aren’t. The finding is measuring conformance to a checklist, not risk. Let’s understand why this is!

What DNSSEC is, and what it’s actually for

DNS is the internet’s address book. By default it’s trusting: when your resolver asks “where does this name live?”, it accepts the answer without proof. DNSSEC (DNS Security Extensions) bolts a chain of cryptographic signatures onto DNS so that answers can be proven authentic and unaltered, all the way up to the signed root.

Two things matter, and almost every scary writeup gets at least one of them wrong:

1. DNSSEC protects integrity, not confidentiality. It proves the answer is genuine. It does nothing to hide what you looked up. If your concern is privacy, that’s DoH/DoT/DoQ – a completely different control.
2. Signing your domain only helps people whose resolver validates. There are two halves – publishing signatures on your own zone, and checking other people’s. They’re independent, and most of the world still resolves through paths that happily accept unsigned answers.

The specific threat DNSSEC was built to kill is the forged DNS answer – cache poisoning (the 2008 Kaminsky attack) and on-path tampering that silently redirects you to infrastructure an attacker controls. That’s it. That’s the whole job.

What already covers most of that risk

Here’s the part the red finding never mentions: in 2026 the threat DNSSEC addresses is, for most organisations, already contained by controls you almost certainly have.

Even if an attacker successfully forged your DNS answer, where does the victim land? On a server that can’t present a valid TLS certificate for your name. The browser refuses the connection. So the real backstop is:

• HTTPS/TLS everywhere – the certificate check makes a forged destination useless.
• HSTS and HSTS preload – force HTTPS from the first request, closing the strip-to-plaintext gap.
• Certificate Transparency monitoring – catch fraudulent certificate issuance for your names in near real-time.
• CAA records – restrict which CAs may issue for your domain.

And the “DNS hijacks” that actually make the news? They’re rarely cache poisoning. They’re registrar account takeovers – someone steals the login and changes your records legitimately. DNSSEC does nothing here, because the attacker just re-signs their own malicious records. What stops that is:

• Registry Lock – no changes without an out-of-band approval step.
• Hardware MFA on registrar and DNS accounts, with least privilege on who can edit zones.
• Monitoring and alerting on NS/MX/A/DS changes.

For email-borne spoofing, you’ve got SPF, DKIM and DMARC, and MTA-STS + TLS-RPT for transport. Notice that none of these need DNSSEC.

The uncomfortable truth for the scorecard: by the time you’ve done TLS, HSTS, CT, CAA, Registry Lock, MFA and DMARC, the residual risk DNSSEC uniquely retires is small and shrinking – and you got there without it.

What DNSSEC can break

This is the half the “CRITICAL” finding never weighs. DNSSEC isn’t free, and its dominant risk isn’t an attacker – it’s DNSSEC itself.

Signatures expire. They have to be re-signed and rolled, flawlessly, forever. Get a key rollover, a signature window, or a DS record wrong – or have the registry above you get it wrong – and a validating resolver doesn’t see “tampering,” it sees “fail,” and your domain vanishes for everyone who validates.

This is not hypothetical. In May 2026, the operator of Germany’s .de served a single malformed DNSSEC signature and millions of domains went dark for hours – every domain under .de, regardless of where it was hosted, because the failure was at the TLD. No hacker. No breach. One broken cryptographic record. The big resolvers recovered by disabling validation for .de, and the registry suspended future key rollovers. There’s a reason a public list of DNSSEC outages exists and keeps growing. Check out the Cloudflare blog here: https://blog.cloudflare.com/de-tld-outage-dnssec/

There’s also a delicious irony for anyone selling DNSSEC as pure defence: signed responses are large, which makes DNS a better DDoS amplification weapon. Deploy it badly and you increase the harm your infrastructure can do to third parties.

And then there’s the island of security – a zone that’s signed but whose parent has no DS record. It looks “signed” to a naive scanner, provides zero actual protection, and is exactly the kind of thing that lets a scorecard tick green while you’ve gained nothing.

What the UK NCSC and HMG actually recommend

If missing DNSSEC were a genuine emergency, you’d expect the UK’s national cyber authority to mandate it. It doesn’t. Government policy treats DNSSEC as discretionary – consider it if appropriate to your capability – and NCSC’s own guidance is openly cautious about the management complexity and the providers that don’t support it.

What HMG does mandate tells you where the real risk is: Registry Lock on government domains (the anti-hijack control DNSSEC doesn’t provide), Protective DNS (blocking access to known-malicious domains), and DMARC. For email in transit, NCSC explicitly steers organisations to MTA-STS – not DANE – to force TLS and resist downgrade attacks, precisely because MTA-STS needs no DNSSEC.

The proof is in our scan: .uk sits at 3.69% signed, versus .nl at nearly 57%. That gap isn’t competence – it’s policy. The Dutch registry incentivises signing; the UK doesn’t. And ncsc.gov.uk itself? Not signed. The national cyber authority runs the exact posture it recommends to everyone else: O365, MTA-STS, no DNSSEC.

You can see this using their own mail check utility (see further down in the post).

Why some countries do require it (and what that proves)

It isn’t universal scepticism. The United States has mandated DNSSEC for federal .gov domains since 2008 (OMB Memorandum M-08-23), and the .gov registry is signed. The Netherlands runs a “comply or explain” regime that puts DNSSEC (and DANE) on the mandatory standards list. Certain sectoral and critical-infrastructure frameworks require it too.

If a regulator or contract names DNSSEC, that ends the debate – you deploy it, and you focus on doing it safely. But here’s the kicker from our data: .gov, under a 17-year-old mandate, came in at about 40% signed. Even when it’s required, four in ten can’t sustain it. The reality is, it’s operational friction, and it’s the single best evidence that this control carries a real running cost.

When DNSSEC is genuinely worth it

I’m not anti-DNSSEC, I am anti FUD, anti scaring people and I’m anti blindly recommending controls which carry real risk on implementation. It’s a sound solution to a narrow problem, and there are clear cases where I’ll actively recommend it:

• You depend on DANE. SMTP DANE – provably-authenticated, downgrade-resistant email between mail servers – is the one widely-relevant feature that only works with DNSSEC. This matters more in 2026 than it did: Microsoft has rebuilt Exchange Online mail flow onto the signed mx.microsoft infrastructure specifically to make inbound DANE possible. If you’re a high-assurance shop that wants DANE rather than MTA-STS, you need to sign – it’s the customer-side half of the deal.
• You’re a high-value target with the maturity to run it (the last part is really important). Your threat model includes answer-tampering your other controls don’t cover (which could be a problem you should focus on…), and you have automated signing plus monitoring so a signature never silently lapses.
• Sovereignty matters. Where vouching cryptographically for your own slice of the namespace is itself the objective.
• A regulator says so. See above.

Notice the common thread: a specific reason and the operational discipline to carry it. Absent both, you’re buying risk, not retiring it.

Why ‘we’ default to not deploying it

Put the two sides on a scale. On one pan: a small, shrinking threat already covered by TLS, CT, Registry Lock and DMARC. On the other: a recurring, self-inflicted availability risk with a blast radius that can include your parent registry’s competence, a DDoS-amplification externality, and a key-management commitment that never ends. For most organisations, that scale tips decisively away from signing.

So our default – and it’s a default, not a religion – is validate, don’t sign. Point your resolvers at validating infrastructure (or use a protective DNS service that validates); that protects your users at zero availability risk to you, because the failure mode isn’t yours to own. Then sign by exception, only where DANE, a regulator, or a concrete threat model justifies taking on the liability – and only if you can operate it without becoming your own most likely cause of an outage.

That’s not cutting a corner. It’s the same conclusion the UK government, and Google, Amazon and Microsoft, all reached independently.

Email Check

NCSC provide a great tool for checking email security configurations (DNS configs): https://checkcybersecurity.service.ncsc.gov.uk/email-security-check

and look, I don’t have DNSSEC enabled on xservus.com or pwndefend.com, that’s not a flaw, that’s a CHOICE!

Summary

• DNSSEC authenticates DNS answers. It protects integrity, not privacy, and only helps users who validate.
• The threat it addresses – forged DNS answers – is largely contained already by TLS, HSTS, Certificate Transparency and CAA, while the hijacks that actually happen are registrar account takeovers that DNSSEC can’t stop (Registry Lock does).
• DNSSEC introduces real, recurring availability risk – expiries, rollovers, TLD-level failures like .de in May 2026 – plus amplification and key-management cost.
• The UK NCSC/HMG treat it as discretionary and prioritise Registry Lock, Protective DNS, DMARC and MTA-STS instead. The US mandates it for federal .gov; the Netherlands via comply-or-explain.
• It’s genuinely worth it for DANE dependencies, high-assurance targets with the ops maturity to run it, sovereignty cases, and anywhere a regulator requires it. (the last part is really important obviously)
• For everyone else, validate by default, sign by exception.

So next time a scorecard tells you a missing DNSSEC record means you’re “totally compromised,” treat it the way you’d treat any vendor turning a checklist item into a fire alarm. Ask what threat it actually retires, what it costs you to run, and whether the controls you already have cover the risk. For most of you, the honest answer is: you’re fine. Go fix something that matters.