DNSSEC explained: should you turn it on?

When someone looks up example.com, their resolver asks a chain of DNS servers and trusts whatever answer comes back. DNSSEC adds signatures to your DNS records, so a validating resolver can check that an answer really came from your DNS provider and wasn't forged or altered on the way.

What it protects against

Forged DNS answers: an attacker who poisons a resolver's cache or sits on the network path can't hand out a fake address for your website or mail server without the signature failing.

Validation happens at the resolver. Google Public DNS (8.8.8.8) and Cloudflare (1.1.1.1) both validate, as do many ISPs' resolvers.

What it doesn't protect against

Someone getting into your registrar or DNS account. They can change your records, and the provider signs them like any other change. Two- factor login and registry lock protect against that; DNSSEC doesn't.
Privacy. DNSSEC signs answers; it doesn't encrypt them.
Lookalike domains. examp1e.com can be signed too.

How it fits together

Two places hold DNSSEC data:

Your DNS provider signs your records (the DNSKEY and RRSIG records).
The registry, through your registrar, holds a DS record: a fingerprint of your DNS provider's key. That's what links the chain of trust from the TLD down to your zone.

Both must match. That's the source of nearly every DNSSEC outage.

Turning it on (Cloudflare example)

In Cloudflare, go to DNS → Settings and choose Enable DNSSEC. Cloudflare shows the DS record values (algorithm 13, ECDSA P-256 with SHA-256).
At your registrar, add that DS record to the domain.
Wait for the registry to publish it, then check with a DNSSEC tester or dig +dnssec example.com.

If the domain is registered at Cloudflare Registrar, Cloudflare adds the DS record for you, usually within a day or two. Some registries (.ch, .li, .se and others) also pick up the DS record automatically from CDS records your DNS provider publishes (RFC 8078).

The mistake that takes domains offline

Changing DNS provider, or nameservers, while the old DS record is still at the registry. Validating resolvers fetch your new provider's records, check them against the old provider's fingerprint, find they don't match, and return SERVFAIL: to those users, your website and email simply stop existing. Non-validating resolvers keep working, so it looks intermittent and is hard to diagnose.

Two safe ways to move:

Turn DNSSEC off first. Remove the DS record at the registrar, wait at least the DS record's TTL (often a day or two) plus a margin, then change nameservers, then turn DNSSEC on at the new provider and add its DS record.
Multi-signer migration. Some providers, Cloudflare among them, support moving with DNSSEC on, by importing each other's keys first. Both providers must support it; follow their steps exactly.

The same applies in reverse: if someone changes your nameservers without permission and leaves your DS record, the domain breaks for validating resolvers. See nameservers changed without permission.

Should you turn it on?

Yes, if your DNS provider and registrar handle it for you (the same company, or a registry that reads CDS records). The risk of a broken DS record is then small.
Yes, if you want DANE for email: Exchange Online's inbound DANE, for example, requires DNSSEC on your domain. For most domains, MTA-STS is the easier way to protect mail in transit.
Think twice if DNS and registrar are separate and nobody owns the process. A forgotten DS record during a future migration can take the domain down. Write the "remove DS first" step into your runbook.

Check your domain

The free scan checks your domain's registration, nameservers, transfer lock and email records. Nameward's monitoring alerts you if the registrar or nameservers change, the moment a DS record mismatch would start to matter.

DNSSEC explained: what it protects, and how not to break your domain