What on earth is DNSSEC, and should your business care?

DNS is the part of the internet that turns a name you can read into a number a computer can route to. You type a domain, DNS hands back an address, your traffic goes there. The uncomfortable thing about it: by default, nothing checks that the answer you got back is the real one.

DNSSEC is the fix for that. Like most security that works quietly in the background, it's widely misunderstood, usually oversold by one vendor and dismissed as "too complicated" by the next. Here's the version without the hand-waving.

What problem does DNSSEC actually solve?

Plain DNS is trusting. When your resolver asks "what's the address for yourdomain.com?", it accepts the first plausible answer that comes back. There's no signature on it. No proof it came from the real owner of the domain.

That gap has a name: cache poisoning. An attacker who can slip a forged answer to a resolver, before the real one arrives or by other means, can make that resolver hand out a wrong address to everyone who asks. Your customers type your domain and land on someone else's server. Mail meant for you routes somewhere else. The domain looks fine. The answers are lies.

DNSSEC closes the gap by signing DNS answers cryptographically. A DNSSEC-aware resolver can check the signature and prove the answer genuinely came from the domain's owner and wasn't tampered with on the way.

One thing it is not, because this trips people up constantly:

DNSSEC authenticates DNS answers. It does not encrypt them. Anyone watching the wire can still see which domains you look up. DNSSEC only guarantees the answer is genuine, not private. Privacy is a different tool (DNS-over-HTTPS or DNS-over-TLS).

How does it work, without the maths?

You don't need the cryptography to run it, but the shape is worth knowing, because it explains the one risky operation.

It's a chain of trust built from three record types. DNSKEY holds the public keys your domain uses to sign its records. RRSIG holds the actual signatures, one attached to each set of records. DS is a fingerprint of your key, published one level up at your registry, via your registrar.

yourdomain.com.  DNSKEY  ...   (your signing keys)
yourdomain.com.  RRSIG   ...   (signatures over your records)
com.             DS      ...   (fingerprint of your key, held by the registry)

The magic is in the linkage. The .com registry vouches for your key, via the DS record. The root vouches for .com. So a resolver can walk the chain from the root down to your domain, checking each signature, and end up certain the answer for yourdomain.com is authentic. Break any link and validation fails, which is the point, and also the catch.

The one operation that carries risk is the DS record at your registrar. It's the link between your DNS and the chain above you. Get it wrong, or let it fall out of sync with your keys, and resolvers that validate will decide your whole domain is forged and stop resolving it. More on that below.

Where does it genuinely help the business?

Three real benefits, in plain terms.

It makes your domain much harder to hijack at the DNS layer. Cache-poisoning a DNSSEC-signed domain doesn't work, because forged answers fail signature validation and get thrown away. For a domain that carries your brand, your logins, or your money, that's a concrete reduction in a real attack class.

It's the bedrock under modern mail security, and this is the one most people miss. DANE, the standard that lets you pin your mail server's TLS certificate in DNS so it can't be downgraded or swapped, only works on a DNSSEC-signed domain. No DNSSEC, no DANE. If you care about properly secured mail transport, DNSSEC isn't optional. It's the foundation the rest stands on.

And it satisfies a growing list of compliance and procurement asks. Government, finance, and a rising number of enterprise security questionnaires now ask whether your domain is signed. A clean "yes" removes a line of friction.

What does it cost you?

Honesty time. It's not free of effort.

There's key management. Signed zones have keys, and keys roll over. Most managed DNS providers now handle this automatically: you click a button and they sign the zone and rotate keys for you. If you run your own DNS, it's real operational work.

There's the registrar DS step. After your DNS is signing, you must publish the DS record at your registrar to complete the chain. This is a manual step on most registrars, and it's the one that's easy to fumble.

And the failure mode is total, not partial. This is the part to respect. There's no "mostly working" with DNSSEC; it's a light switch wired to a trapdoor. A broken signature or a stale DS record doesn't degrade gracefully. To a validating resolver, your domain simply stops existing: no error page, no half-loaded site, just a domain that quietly ceases to be until someone fixes it. A botched key rollover can take you fully offline for everyone using a validating resolver. That's why the boring advice, use a provider that automates rollovers and change the DS record only as part of a deliberate process, is the right advice.

Our take

For most organisations on a managed DNS provider, DNSSEC is a button worth pressing, provided the provider automates key rollovers, which the good ones do. The hijack-resistance is real, and if mail security (DANE) is anywhere on your roadmap, you need DNSSEC first regardless.

The caution is genuine but narrow. It's not "DNSSEC is dangerous", it's "the DS record and key rollovers are the sharp edges, so let automation handle them and don't hand-edit the chain casually." Press the button on a provider that does the hard part for you, and the day-to-day cost is close to zero. Hand-edit the DS record at 4pm on a Friday, and you'll find out what "total failure mode" means the hard way.

What to do

1. Check whether you're already signed. Run your domain through the DNSSEC checker. It'll show your DS, DNSKEY, and whether the chain validates.
2. If you're not signed and you're on managed DNS, enable DNSSEC in the provider's panel, then publish the DS record it gives you at your registrar. Confirm the chain validates afterwards. Don't assume.
3. If mail security is on your list, treat DNSSEC as step zero. Once it's solid, DANE becomes available to pin your mail server's certificate.
4. Leave key rollovers to automation. If your provider rolls keys for you, let it. The only thing you touch by hand is the initial DS, and only deliberately.