DNSSEC and DNS security
Signing a zone and the chain of trust, DS records and key rollover, validating resolvers, the misconfigurations behind DNSSEC outages, and other DNS-layer attacks.
Signing and the chain of trust
DNSSEC adds signatures to DNS answers so a validating resolver can prove the answer came from the zone and was not altered in transit. It does not encrypt anything - queries and answers remain visible to anyone on the path.
The chain, from the root down
the root zone publishes a DS record for .com
.com publishes a DS record for example.com
example.com publishes DNSKEY records, and the parent's DS matches one of them
answers are signed with the zone's private key (RRSIG)
If any link is missing or mismatched, a validating resolver returns SERVFAIL
- not the unsigned answer. That is why DNSSEC mistakes break a zone hard.| Record | Purpose | Published by |
|---|---|---|
DNSKEY | The public keys for the zone | The zone itself |
RRSIG | A signature over a record set | The zone itself |
DS | A hash of a child's key, signed by the parent | The parent zone |
NSEC | Proves a name does not exist | The zone itself |
NSEC3 | The same, hashed to avoid name enumeration | The zone itself |
CDS / CDNSKEY | A child asking the parent to update the DS | The zone itself |
Keys and rollover
- Enable DNSSEC at the provider. Most generate a key-signing key and a zone-signing key and publish the DNSKEY set.
- Publish the DS record in the parent. With a registrar that supports it, this is one click; otherwise it is a manual record change and can take a day to appear.
- Verify with a validating resolver - a query that returns the
adflag proves validation succeeded. - Monitor the signature expiry. Zone signatures have a validity period and an expiry date; an expired signature breaks the zone for every validating resolver.
- Roll keys on a schedule, publishing the new key and DS before switching, and keeping the old one until every cached copy has expired.
dig +dnssec example.com @1.1.1.1 | grep -E "flags:|RRSIG|ad;"
dig DS example.com @a.gtld-servers.net +short
dig DNSKEY example.com @ns1.example.com +short
# a validating resolver sets the AD flag when it has verified the chain
dig +dnssec +short example.com @8.8.8.8- Delay publishing a DS record until the zone's signatures are confirmed working. A DS published before the keys are live creates an immediate validation failure.
- Keep the previous key published for longer than the maximum TTL in the zone, plus the resolver's own cache behaviour. Cutting it short strands clients mid-rollover.
- Some CDNs and providers perform the rollover for you. If they do, verify the DS record matches what is currently live.
What DNSSEC does not solve
| Attack | DNSSEC helps? | Actual defence |
|---|---|---|
| Spoofed answer on the path | Yes, validation rejects it | DNSSEC plus an encrypted transport |
| Cache poisoning | Yes, much harder | Patched resolvers and DNSSEC |
| DNS rebinding | No | Validate the Host header and use a public DNS pinning policy |
| Query observation | No | DNS over HTTPS or TLS |
| Zone transfer theft | No | Restrict AXFR to known secondaries |
| Registrar account takeover | No | Hardware-key two-factor and registry lock |
| Dangling CNAME to a released service | No | Audit records and remove stale targets |
# common DNSSEC failures and where to look
SERVFAIL from validating resolvers, NOERROR from others
-> the DS record does not match any DNSKEY, or a signature expired
Everything works except on one network
-> that resolver validates and upstream data is broken; check the chain
Signatures valid but the zone does not load
-> an NSEC3 chain gap, or a record added without re-signing
# verify before and after every rollover
dig +dnssec example.com @1.1.1.1 | grep -q "flags:.* ad" && echo "validating OK"⚠️
DNSSEC failures are total, not partial. An unsigned zone with a bad record serves a wrong answer to one person; a signed zone with a broken chain serves nothing at all to every validating resolver. Enable it on a domain you can afford to test, with the DS record change planned and reversible.
FAQ
Should every site enable DNSSEC?
It is worth doing for any domain where an attacker redirecting traffic would cause real damage. It adds operational risk, so enable it deliberately and monitor signature expiry.
Does DNSSEC hide my records?
No. It proves authenticity and integrity, not confidentiality. Anyone can still see every answer in the clear unless the transport is encrypted.
Related
Anycast, GeoDNS and traffic steering Troubleshooting DNS with dig and online tools
Last refreshed 2026-09-18.