Plain DNS has no way to prove an answer is genuine. An attacker who can inject or spoof responses can send users to the wrong IP (“cache poisoning”). DNSSEC (DNS Security Extensions) adds digital signatures to DNS records, so validating resolvers can verify that answers really come from the domain’s owner and weren’t modified on the way.

DNSSEC protects authenticity and integrity, not privacy. Queries remain visible unless you also use encrypted DNS. See DNS over HTTPS and TLS.

How it works

  1. The zone’s records are signed. Each record set gets an RRSIG (signature) record.
  2. The zone publishes its public keys in DNSKEY records:
    • ZSK (zone signing key) signs the records;
    • KSK (key signing key) signs the DNSKEY set.
  3. The parent zone (e.g. .com) publishes a DS record, a hash of your KSK, signed by the parent’s own keys.
  4. That continues up to the root, whose key is built into validating resolvers as the trust anchor.
root (trust anchor)
 └─ .com   (DS for example.com, signed by .com)
     └─ example.com  (DNSKEY, RRSIGs on A, MX, TXT…)

A validating resolver (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9, Unbound) follows this chain. If a signature doesn’t verify, it returns SERVFAIL instead of a forged answer.

Non-existence is signed too (NSEC/NSEC3 records), so attackers can’t fake “this name doesn’t exist”.

Enabling DNSSEC

There are two parts. Your DNS host signs the zone, and your registrar publishes the DS record at the parent.

Managed DNS (Cloudflare and most providers)

  1. In the DNS provider’s dashboard, enable DNSSEC. It generates keys and signs automatically.
  2. It shows the DS record values (key tag, algorithm, digest type, digest).
  3. At your registrar, add the DS record. Some registrar–DNS combinations do this automatically (when the registrar is also the DNS host, or via CDS/CDNSKEY automation).
  4. Wait for the parent zone to publish it (minutes to a few hours).

Self-hosted authoritative DNS

PowerDNS signs with one command (pdnsutil secure-zone example.com). BIND has dnssec-policy. Both then show the DS record for your registrar. See PowerDNS.

Verify

dig example.com A +dnssec            # RRSIG records present
dig example.com DNSKEY +short
dig example.com DS +short            # DS at the parent
dig @1.1.1.1 example.com A +dnssec   # look for the "ad" flag (authenticated data)
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2 …

The ad flag means the validating resolver verified the chain. Online tools (DNSViz, Verisign’s DNSSEC Debugger) visualise the whole chain and point out errors. See dig.

The big risk: misconfiguration breaks everything

With DNSSEC, mistakes don’t degrade gracefully. If the DS at the parent doesn’t match the zone’s keys, every validating resolver returns SERVFAIL, and the domain disappears for a large share of internet users.

Common causes:

  • Changing DNS providers (nameservers) without handling DNSSEC: the old DS still points to keys the new provider doesn’t have. Disable DNSSEC and remove the DS before switching (or do a proper key rollover with both providers). See nameservers explained.
  • Wrong DS values entered at the registrar (typos, wrong algorithm or digest type).
  • Expired signatures on self-hosted setups when signing automation stops.
  • Key rollovers done in the wrong order.

Safe practice: use a DNS host that automates signing and rollover, monitor DNSSEC validity (DNSViz, monitoring checks), and keep the “disable DNSSEC first” step in every migration checklist.

Should you enable it?

Pros:

  • protects against DNS spoofing and cache poisoning for users of validating resolvers;
  • a prerequisite for DANE (TLS certificate pinning in DNS, used mainly for SMTP between mail servers);
  • required by some registries, governments and security policies.

Cons:

  • an extra failure mode during DNS changes;
  • slightly larger responses, which need TCP or EDNS for big answers;
  • doesn’t encrypt anything.

With a managed DNS provider that handles keys automatically, enabling DNSSEC is low-effort and recommended for most production domains. Be deliberate about it on self-hosted DNS.

Validating DNSSEC on your servers

Make your servers validate answers too, so the server itself is protected:

  • systemd-resolved: DNSSEC=yes (or allow-downgrade) in /etc/systemd/resolved.conf;
  • Unbound validates by default with a root trust anchor. See Unbound.

Test validation with the intentionally broken domain dnssec-failed.org. A validating resolver returns SERVFAIL.

Quick reference

Record Purpose
RRSIG Signature over a record set
DNSKEY Zone’s public keys (ZSK, KSK)
DS Hash of the KSK, published in the parent zone
NSEC / NSEC3 Signed proof that a name doesn’t exist
Task Command
Check signatures dig example.com +dnssec
Check DS at parent dig example.com DS +short
Validation flag ad in dig @1.1.1.1 output

Related: CAA records and DNS records explained.

  • DNS
  • Security
  • Domains