What Is DNSSEC and Should You Enable It?

Plain DNS has no way to tell you whether an answer is genuine. A resolver asks "what's the address for example.com?", something replies, and the resolver believes it. If an attacker can get a forged answer in first, the resolver caches it and everyone using that resolver goes to the wrong place — with the right name in the address bar.

DNSSEC closes that gap by cryptographically signing DNS records, so a resolver can verify an answer really came from the domain's authoritative servers and wasn't altered in transit.

How it works, briefly

Each record set in your zone is signed with a private key. The matching public key is published in DNS, so a validating resolver can check the signature.

The clever part is the chain of trust. Your zone's key is vouched for by a DS record published one level up — in the parent zone, at the registry. That parent zone is signed too, and vouched for by its parent, all the way to the DNS root. A resolver that trusts the root can therefore verify any signed domain beneath it.

That chain is the whole design, and it's also where the operational risk lives. If the DS record at the registry doesn't match the key your nameservers are actually signing with, validation fails — and validating resolvers refuse the answer entirely. Not "fall back to unsigned"; refuse. To users, the domain simply stops existing.

What DNSSEC does and doesn't protect

Worth being precise, because it's frequently oversold:

It does protect against cache poisoning and forged DNS answers — an attacker injecting a bogus address for your domain into a resolver's cache.

It does not protect against:

Anyone who controls your DNS. If an attacker can log into your DNS provider, they can sign whatever they like. DNSSEC proves an answer is authentic, not that it's the one you wanted.
Traffic interception after resolution. That's TLS's job.
Anything about the content of your site.
Privacy. DNSSEC signs; it doesn't encrypt. Queries remain visible.

And its benefit only materialises when the resolver validates. Many do — the large public resolvers among them — but plenty don't, so protection is partial by nature.

The case for turning it on

It closes a real attack class. Cache poisoning is not theoretical.
Some TLDs and sectors expect it. A number of ccTLDs push it hard, and it's often required in government and financial contexts.
It's a prerequisite for other things. DANE, and some email-authentication hardening, depend on it.
It's usually one click. If your registrar and DNS host are the same provider, enabling DNSSEC often means toggling a setting and letting them handle the keys and the DS record.

The case for caution

The honest counterweight: DNSSEC is the setting most likely to take your domain fully offline, and the failure is total rather than partial.

The dangerous moment is migration. Move DNS hosting — or transfer the domain — with DNSSEC enabled, and the DS record at the registry still points at the old provider's key while the new provider signs with a different one. Validating resolvers now see a broken chain and refuse to resolve the domain at all. Your site, your email, everything.

The correct sequence when moving:

Disable DNSSEC first and remove the DS record at the registry.
Wait for the old DS record's TTL to expire — this is not optional, and TLD-level TTLs can be long (why DNS changes take time).
Migrate the DNS hosting or transfer the domain.
Re-enable DNSSEC at the new provider and publish the new DS record.

Rushing step 2 is the classic way to produce an outage that looks inexplicable — the records are all correct, and the domain still doesn't resolve.

The other failure mode is key rollover on a setup where you manage keys yourself. Providers that handle rollover automatically make this a non-issue; DIY signing means it's your responsibility, and a missed rollover breaks the chain the same way.

So should you?

A reasonable default:

Your registrar and DNS host are the same, and they offer one-click DNSSEC → turn it on. The risk is low and largely managed for you.
You're in a sector where it's expected → turn it on, and document the migration procedure above somewhere findable.
You self-manage signing, or split registrar and DNS host across providers → worth doing, but treat it as infrastructure with a runbook, not a checkbox.
You're about to migrate providers → do the migration first, then enable it. Don't do both at once.

The one thing not to do is enable it, forget it, and then let someone migrate DNS eighteen months later without knowing it's on. That's the sequence that produces the outage.

Checking your current state

Our free WHOIS & DNS lookup shows whether a domain is DNSSEC-signed, alongside its nameservers and the rest of its records — a quick way to audit what you actually have, including domains you inherited and never configured. How to read a WHOIS record and your DNS settings walks through the rest of the fields.

Because a broken DNSSEC chain and an unauthorised nameserver change look similar from outside — the domain stops working correctly and nothing in your dashboard looks wrong — it's worth having these tracked. DomainChest records each domain's DNSSEC state and nameservers and alerts when they change, so a migration that half-completed surfaces as a notification. See DNS change monitoring.