Guide

DNSSEC. Signing Your DNS Without Breaking It

Cryptographic proof that your DNS answers are real. Why it matters, how to enable it safely, and the one mistake that takes your whole domain offline.

9 min read·Updated Jun 10, 2026
TL;DR
DNSSEC signs your DNS records so resolvers can prove the answers weren't forged. Enabling it is usually one toggle at your DNS host plus a DS record at your registrar. The danger is the mismatch case: a DS record pointing at a key your nameservers no longer serve takes your whole domain offline. Enable it, then monitor the chain.

What is DNSSEC?

DNS was designed in 1983 with zero authentication. When your laptop asks "what's the IP for example.com?", it accepts the first plausible-looking answer that arrives. An attacker who can race or poison that answer can redirect your visitors, your email, or your password resets anywhere they like. Cache poisoning attacks against this weakness are real and documented.

DNSSEC (DNS Security Extensions) fixes this by signing every record set in your zone with a private key. Your DNS host publishes the matching public key as a DNSKEY record, and a hash of that key, the DS (Delegation Signer) record, is placed in the parent zone via your registrar. Validating resolvers walk the chain: the root signs .com's keys, .com signs your DS, your DS vouches for your DNSKEY, and your DNSKEY signs your actual records. Forge any link and validation fails.

Why it matters

  • It protects everything else: Your SPF, DKIM, DMARC, MX, and CAA records are all just DNS. If an attacker can spoof your DNS answers, every other control you've configured is built on sand.
  • It enables DANE: TLSA records for SMTP, which let receiving servers pin your mail server's certificate, require DNSSEC. Several European mail providers validate DANE today.
  • Trust signals: Some compliance frameworks (and government procurement checklists, especially in the EU and Netherlands) now expect DNSSEC on corporate domains.

How to check your domain

# Does a DS record exist at the parent?
dig example.com DS +short

# Does validation succeed? Look for the "ad" flag.
dig @8.8.8.8 example.com SOA +dnssec

If dig returns SERVFAIL from 8.8.8.8 but works with +cd (checking disabled), your DNSSEC chain is broken, not merely absent. That's an outage in progress for everyone behind Google DNS, Cloudflare DNS, Quad9, and most ISP resolvers.

How to enable DNSSEC, step by step

  1. Check your DNS host supports it. Cloudflare, Route 53, Google Cloud DNS, and most modern hosts sign zones with one click. If yours doesn't, consider migrating before bolting on manual signing.
  2. Enable signing at the DNS host. The host generates the keys, signs the zone, and shows you the DS record details: key tag, algorithm (13, ECDSA P-256, is the modern default), digest type, and digest.
  3. Publish the DS record at your registrar. Log in to the registrar (not the DNS host, unless they're the same company), find the DNSSEC section, and paste the DS values. Some registrar/host pairs automate this via CDS records.
  4. Wait and verify. Parent-zone updates take minutes to hours. Then confirm with dig +dnssec that you get the ad flag and no SERVFAIL.
Critical
The single worst DNSSEC failure: a DS record at the registrar pointing to a DNSKEY your nameservers no longer serve. This happens when people switch DNS providers and forget the DS, or when a host rolls keys without updating the parent. The result is not "DNSSEC off", it's total resolution failure for your domain, your website, and your email, for everyone using a validating resolver. Always remove the DS record before migrating DNS providers, wait out the TTL, then re-enable at the new host.

Common mistakes

  1. Stale DS after a DNS migration. Described above. The most common and most catastrophic.
  2. Enabling at the host but never publishing the DS. The zone is signed but nothing validates it. Harmless, but you're getting zero protection while believing you're covered.
  3. Manual key rollovers gone wrong. If you self-host DNS and rotate keys, you must publish the new DNSKEY, wait for TTLs, update the DS, wait again, then retire the old key. Skipping a wait step breaks validation. Managed hosts handle this for you, let them.
  4. Expired signatures. RRSIG records carry expiry timestamps. Self-hosted signers that stop re-signing (cron died, disk full) produce a zone that goes invalid on a timer. From the outside it looks fine until the day it doesn't.
  5. Assuming DNSSEC means encrypted DNS. It doesn't. It's authenticity, not privacy.

Monitoring DNSSEC going forward

DNSSEC failures are uniquely silent from the inside: your own infrastructure resolves fine (your resolver may not validate), while half the internet gets SERVFAIL. The things worth watching continuously:

  • The DS record exists and matches a currently served DNSKEY.
  • Validation actually succeeds from a validating resolver.
  • RRSIG signatures aren't approaching expiry.
  • The DS record changes, an unexpected change can indicate a registrar account compromise.

DomainsDoc checks your DNSSEC chain on every scan, alongside SPF, DKIM, DMARC, MX, SSL, and the rest, and alerts you the moment the DS/DNSKEY pair stops matching or validation starts failing. Add your domain and you're covered; see pricing for check frequency by plan.

Frequently asked questions

What is DNSSEC in plain English?
DNSSEC adds cryptographic signatures to your DNS records so resolvers can verify the answers they receive actually came from you and were not tampered with in transit. Without it, DNS answers are just unauthenticated UDP packets that anyone in the right network position can forge.
Does DNSSEC encrypt my DNS traffic?
No. DNSSEC provides authentication and integrity, not confidentiality. Anyone watching the wire can still see which domains are being looked up. Encryption of DNS queries is a separate technology (DNS over HTTPS / DNS over TLS).
Can enabling DNSSEC break my domain?
Yes, and this is the one real risk. If the DS record at your registrar does not match the DNSKEY your DNS host serves (for example, you changed DNS providers and forgot to remove the old DS), validating resolvers treat every answer as forged and your entire domain stops resolving for a large fraction of the internet.
How do I check if my domain has DNSSEC enabled?
Run `dig +dnssec example.com SOA` and look for the AD (authenticated data) flag from a validating resolver like 8.8.8.8, or `dig example.com DS` to see whether a DS record exists at the parent. DomainsDoc checks both the DS record and the full validation chain on every scan.
Do I need DNSSEC for email deliverability?
It is not a hard requirement the way SPF or rDNS are, but it underpins DANE (TLSA records for SMTP), which some European providers and government systems require. It also protects your MX, SPF, and DKIM records from spoofing, which is the foundation everything else stands on.
What happens when I switch DNS providers with DNSSEC enabled?
You must either remove the DS record at the registrar before migrating (going temporarily unsigned), or do a coordinated multi-signer migration. If you just repoint nameservers while the old DS is still published, your domain goes dark for everyone behind a validating resolver.
Stop reading. Start monitoring.

Continuous SPF, DKIM, DMARC, blacklist, SSL, and uptime checks. Alerts the moment something breaks.

Start free
Keep reading