What DNSSEC protects against, and what it does not

14 October 2026 · Grace

DNSSEC is often described as "encrypting DNS". It does not encrypt anything. Understanding what it actually does makes both its value and its risks obvious.

The problem it solves

A plain DNS answer is an unsigned packet. Nothing in it proves it came from the right server. A resolver asks "what is the address of example.com" and believes whatever arrives first and looks plausible.

That is exploitable. An attacker who can guess or observe the query can answer before the real server does — cache poisoning. The resolver caches the forged answer and serves it to everyone behind it until the TTL expires. Every visitor goes to the attacker's address, with no error anywhere, including a valid padlock if the attacker can obtain a certificate.

DNSSEC signs answers so a resolver can verify that what it received is what the zone's owner published, and that nothing was altered on the way.

What it does not do

Be precise about the limits, because DNSSEC is regularly oversold:

• It does not encrypt. Every query and answer remains visible to anyone on the path. Privacy is what DNS-over-TLS and DNS-over-HTTPS are for — a different problem entirely.
• It does not prove a site is trustworthy. It proves the record is the one published. If the domain belongs to a criminal, DNSSEC faithfully proves it is genuinely theirs.
• It does nothing if the resolver does not validate. Signatures are checked by the resolver, not the browser. A resolver that ignores DNSSEC gets no protection, and the user cannot tell.

The chain of trust

Verification works by each level vouching for the one below:

1. Your zone is signed with your keys. Records carry RRSIG signatures.
2. Your public key is published as a DNSKEY record in your zone.
3. A hash of that key is published in the parent zone — .com — as a DS record.
4. The parent zone is itself signed, and its key is vouched for by the root.
5. The root's key is known to the resolver in advance. That is the trust anchor.

The links matter more than the cryptography. A resolver trusts your records because the root vouches for .com, which vouches for you.

The DS record is the join, and it is the one piece that is not in your zone. It lives at the registry and is published through your registrar. Everything that goes badly wrong with DNSSEC goes wrong at that join.

Why it is all-or-nothing

Unsigned DNS fails open — a bad answer is still an answer. DNSSEC fails closed: a validating resolver that cannot verify a signature returns SERVFAIL and gives the user nothing.

That is the point. It is also the risk. A signature mismatch does not degrade the domain, it removes it, for every user of every validating resolver — which today is most of them.

The mistake that causes it is almost always the same: the DS record at the registry no longer matches the keys in the zone. Change DNS providers without removing the DS first, and the new provider's signatures cannot be verified against the old provider's key. The domain does not slow down or half-work. It disappears, and it disappears for everyone except you, because your own resolver may not validate.

Doing it safely

Turning it on is undramatic, providing you follow the order: sign the zone, let the signed records publish, then give the DS record to your registrar. Doing it the other way round — DS first — breaks the domain until signing catches up.

Turning it off is the reverse and matters more: remove the DS at the registrar first, wait for its TTL to expire so no validator still expects a signature, and only then unsign the zone.

Migrating a signed domain is the dangerous one. The simple, safe route is to go unsigned in the middle: remove the DS, wait, migrate, sign at the new provider, publish the new DS. There is a more elegant path where both providers publish each other's keys, but it needs cooperation between them and is not worth attempting unless both document it.

Key rollovers are the routine operation, and modern providers handle them automatically for the zone-signing key. The key-signing key is the one whose rotation requires a new DS at the registrar — so it is the one to be awake for.

Is it worth turning on?

For most domains, yes — the risk is concentrated in a few well-understood moments, and the rest of the time it costs nothing. For a domain where an outage is unacceptable and nobody is confident about the registrar side, an honest "not yet" is better than a signed zone whose DS nobody dares touch.

What decides it is not the cryptography. It is whether the person who will one day migrate the domain knows about the DS record.

KumoDNS signs zones and manages key rollover on paid plans, and shows the DS record to hand to your registrar — see DNSSEC in the wiki.