DNSSEC explained: what it stops, and why we finally turned it on across our own domains
DNSSEC (Domain Name System Security Extensions) has existed since the early 2000s, is free on every major DNS provider, and the majority of domains on the internet still don't have it enabled. We were, until recently, one of them. Here's what it actually protects against, and what turning it on for real looks like.
The gap DNS has always had
When a browser looks up a domain, it asks a DNS resolver "what's the address for this name?" and trusts whatever answer comes back. Standard DNS has no way to verify that answer is authentic — no signature, no way to detect if it was altered in transit. An attacker in a position to intercept or forge that response (a compromised resolver, a man-in-the-middle on the network, a poisoned cache somewhere upstream) can redirect a visitor to a server they control, without the browser showing any warning. To the visitor, the address bar shows the right domain name — they're just not actually talking to the right server behind it.
What DNSSEC changes
DNSSEC adds cryptographic signatures to DNS responses. A resolver that supports DNSSEC validation can check that signature against a public key published for the domain, and refuse the response if it doesn't check out. It's the same trust model TLS/HTTPS uses for the content of a page, applied one layer earlier — to the lookup that finds the server in the first place.
Why it's still not the default
Mostly inertia. Turning it on isn't a single click in most setups — it involves two separate systems (your DNS provider and your domain registrar) that have to agree, and getting the order wrong can, in rare misconfigurations, actually make a domain briefly unreachable. That risk, plus "it's not blocking anything today," is enough for most domains to never get around to it.
What actually turning it on looks like
In practice, on a domain using Cloudflare for DNS: enabling DNSSEC in the Cloudflare dashboard generates a DS record — a hash of the domain's public signing key. That record then needs to be added at the domain's registrar (wherever the domain itself was purchased, which is often a different company than whoever hosts the DNS). Some registrars accept the DS record directly; others — we ran into this on a .co.uk domain via Hostinger — ask for the raw DNSKEY fields instead (flags, algorithm, protocol, public key), which Cloudflare's dashboard also provides, just under a different tab. Once that record propagates (usually minutes to a few hours), the chain of trust is complete and independently verifiable with a plain dig DS yourdomain.com query against any public resolver.
We did this across three domains in one afternoon, side by side with a broader security pass — DNSSEC is genuinely one of the more "turn it on and forget it" items on a list that also includes things needing real ongoing attention.
Should you bother?
If your DNS is already on a modern provider (Cloudflare, Route53, most others), yes — the cost is a few minutes plus whatever it takes to get one DNS record added at your registrar, and it closes a class of attack that's genuinely hard to detect after the fact. It won't show up as a "critical" finding on most scanners, and it doesn't need to — it's cheap insurance against something rare but nasty, not a fire to put out today.