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.
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 +dnssecIf 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
- 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.
- 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.
- 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.
- Wait and verify. Parent-zone updates take minutes to hours. Then confirm with
dig +dnssecthat you get theadflag and noSERVFAIL.
Common mistakes
- Stale DS after a DNS migration. Described above. The most common and most catastrophic.
- 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.
- 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.
- 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.
- 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?
Does DNSSEC encrypt my DNS traffic?
Can enabling DNSSEC break my domain?
How do I check if my domain has DNSSEC enabled?
Do I need DNSSEC for email deliverability?
What happens when I switch DNS providers with DNSSEC enabled?
Continuous SPF, DKIM, DMARC, blacklist, SSL, and uptime checks. Alerts the moment something breaks.