DNSSEC
DNSSEC adds a chain of digital signatures to DNS answers so resolvers can verify that records truly come from the zone owner and were not tampered with in transit.
Definition
DNSSEC is a suite of extensions that signs zone data with asymmetric keys. Each signed record set carries an RRSIG, the public keys live in DNSKEY records, and a delegation signed DS record in the parent zone builds a trust chain from the root. It guarantees authenticity and integrity, not confidentiality.
Context and scope
Deployed on domains where answer integrity matters: mail exchange records protecting against intercept, financial and login domains, registries and registrars. Validators run in resolving services and some operating systems.
Common misconceptions
- DNSSEC encrypts DNS traffic — it signs answers; queries and responses remain plaintext and observable
- DNSSEC stops cache poisoning entirely — it detects tampering but unsigned or bogus zones fall back to failure
- Signing once is enough — key rollovers are recurring operations, and a broken chain makes the domain resolve as bogus
Anti-patterns
- Signing a zone but never automating ZSK and KSK rollover, eventually serving expired signatures
- Publishing DS records at the parent while the child zone serves mismatched keys, producing SERVFAIL for validators
- Forgetting negative-answer proofs: NSEC or NSEC3 must cover denials or attackers forge nonexistent names
Related concepts
Related examples
Authoritative source
What it is
Classic DNS answers carry no proof of origin, so an on-path attacker or a poisoned cache can redirect users. DNSSEC attaches signatures that resolvers verify up the hierarchy to the signed root. A validating resolver returns SERVFAIL when the chain is broken rather than risking forged data.
How it works
The zone signs each record set with a zone signing key; the key signing key signs the DNSKEY set; the parent publishes a DS hash anchoring the delegation. RRSIG timestamps bound validity, so signatures expire and must be re-signed on schedule. NSEC and NSEC3 records prove that a name does not exist.
When to use it
MX records for mail integrity, NS and address records for service redirection, and any domain whose compromise redirects users to attacker infrastructure. Recursive resolvers such as unbound or systemd-resolved validate by default, which makes operational mistakes immediately visible.
Pitfalls
Expired signatures or botched rollovers take the whole domain dark for validators, which is why monitoring RRSIG expiry is the core operational task. NSEC permits zone walking while NSEC3 hashes names. DNSSEC data enlarges responses, worsening fragmentation and amplification considerations.