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

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](/guides/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)

1. In Cloudflare, go to **DNS → Settings** and choose **Enable DNSSEC**.
   Cloudflare shows the DS record values (algorithm 13, ECDSA P-256 with
   SHA-256).
2. At your registrar, add that DS record to the domain.
3. 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](/guides/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](/guides/mta-sts-tls-rpt) 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](/#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.

## Sources

- [RFC 4033: DNS security introduction and requirements](https://www.rfc-editor.org/rfc/rfc4033)
- [RFC 4035: DNSSEC protocol modifications (4.3, 5.5)](https://www.rfc-editor.org/rfc/rfc4035)
- [RFC 8078: Managing DS records from the parent via CDS/CDNSKEY](https://www.rfc-editor.org/rfc/rfc8078)
- [Cloudflare: DNSSEC](https://developers.cloudflare.com/dns/dnssec/)
- [Cloudflare: Migrate an existing zone with DNSSEC enabled](https://developers.cloudflare.com/dns/dnssec/dnssec-active-migration/)
- [Google Public DNS: Security](https://developers.google.com/speed/public-dns/docs/security)
- [Cloudflare 1.1.1.1: FAQ](https://developers.cloudflare.com/1.1.1.1/faq/)
- [SWITCH: CDS for .ch and .li](https://www.nic.ch/security/cds/)
- [Microsoft: How DANE secures email](https://learn.microsoft.com/en-us/exchange/security-and-compliance/how-dane-secures-email)

---
Source: https://nameward.app/guides/dnssec-explained (updated 2026-10-31)