DNSSEC
DNSSEC (DNS Security Extensions) is a set of protocol extensions that lets resolvers cryptographically verify that DNS answers haven't been tampered with in transit. It doesn't encrypt DNS: it signs it.
How it works
The zone publishes its public key as a DNSKEY record. Each record in the zone is accompanied by an RRSIG signature. Resolvers fetch the DNSKEY, verify the RRSIG, and reject the answer if the signature doesn't match.
Chain of trust
Verifying the DNSKEY itself is the next problem. The parent zone publishes a hash of the child's DNSKEY as a DS record. Resolvers walk up the tree: child DNSKEY verified by parent DS, parent DNSKEY verified by grandparent DS, all the way up to the root, whose key is hard-coded into resolvers (the "trust anchor").
Worked example: a botched key rollover
You're rotating your zone-signing key. The process is: publish the new DNSKEY alongside the old one, wait for caches to converge, sign with the new key, wait again, then remove the old DNSKEY. Skipping the wait windows is the canonical DNSSEC outage.
What goes wrong: you publish the new DNSKEY and immediately start signing with it, removing the old key. Resolvers that cached the old DNSKEY (TTL maybe 3600) now see RRSIGs made with a key they don't have. They fail validation and return SERVFAIL. The domain disappears for every DNSSEC-validating resolver — about 25% of global queries — for up to one hour. WhereIsDNS will show a fan of timeouts and errors across the validating resolvers while the rest still serve cached good answers.
The fix: rolled-over keys must overlap their RRSIG-signing windows by at least the maximum DNSKEY TTL on both sides. Most DNS providers automate this correctly. Don't roll keys manually unless you've read RFC 6781 twice.
Why deployment is uneven
Enabling DNSSEC at your DNS provider isn't enough: you also have to upload the DS record at the registrar (the parent zone). Many people enable DNSSEC at the provider, miss the registrar step, and end up with a broken chain. Resolvers that validate DNSSEC return SERVFAIL in that case, even though the records "exist."
Algorithm choices
RFC 8624 currently recommends ECDSA P-256 (algorithm 13) or Ed25519 (algorithm 15). The older RSA-SHA256 (algorithm 8) still dominates the installed base. RSA-SHA1 (algorithms 5 and 7) is deprecated — if your provider still uses it, switch.
Trade-offs
DNSSEC adds query overhead (more records to fetch), is operationally fragile (a botched key rollover takes a domain offline), and doesn't address the harder problems (eavesdropping is solved by DoH/DoT, not DNSSEC). Adoption is non-universal: in late 2025, around 8% of .com zones were DNSSEC-signed.
Verify on WhereIsDNS
Run a DNSKEY lookup and a DS lookup on the same domain. If DNSKEY exists but no DS appears at the parent, you have a "DNSKEY published but not anchored" state — DNSSEC isn't actually being validated by resolvers. Add the DS at your registrar to close the chain.
Related: DNSKEY lookup · DS lookup.