Everything so far has assumed DNS answers are true. They do not have to be. DNS was specified without any means for a resolver to tell a genuine answer from a fabricated one, and DNSSEC is the retrofit that fixes exactly that — and nothing else.
The problem
A recursive resolver asks a question and accepts the first plausible-looking reply. Anyone who can get a reply in first — on the network path, or by guessing the query parameters — can supply an answer of their choosing, and the resolver will cache it and serve it to everyone behind it until it expires.
That is cache poisoning, and the consequences are total for the domain concerned: the attacker chooses where the web traffic goes, where the mail goes, and what every TXT-based verification says.
It was made much harder, not impossible
RFC 5452 introduced source-port randomisation and other entropy after a widely publicised weakness in 2008, which made blind guessing impractical. It did nothing about an attacker who can see or modify the traffic, and it is a probability argument rather than a proof. DNSSEC replaces the probability argument with a cryptographic one.
What DNSSEC does
The zone owner signs the zone. Every set of records carries a signature. A validating resolver checks that signature against a key published in the zone, checks that key against a digest published in the parent zone, and so on up to the root — whose key it already holds. If any link fails, the resolver returns SERVFAIL rather than the answer.
| Property | DNSSEC provides it? |
|---|---|
| Authenticity — this answer came from the zone owner | Yes. |
| Integrity — it was not modified in transit | Yes. |
| Authenticated denial — this name genuinely does not exist | Yes, via NSEC/NSEC3. |
| Confidentiality — nobody can see my queries | No. DNSSEC does not encrypt anything. |
| Availability — my zone stays reachable | No. If anything, a signing mistake is a new way to be unreachable. |
DNSSEC is not DNS encryption
This is the most common misconception about it. DNSSEC signs; it does not encrypt. Every query and every answer remain in plain text on the wire and remain visible to anyone on the path. Encrypting DNS traffic is a different problem addressed by DNS over TLS and DNS over HTTPS, which in turn do nothing about authenticity. The two are complementary, not alternatives.
Signing has a failure mode plain DNS does not
Signatures carry explicit expiry dates. A zone that stops being re-signed does not degrade gracefully — at the moment its signatures expire, every validating resolver starts returning SERVFAIL, and the domain disappears for everyone using one.
;; status: SERVFAIL
This is DNSSEC working correctly. The resolver cannot verify the answer, so it refuses to supply one — failing closed is the entire design. It also means signing a zone adds an operational obligation, and that obligation is the subject of the last lesson in this module.
Who actually benefits
- Users behind validating resolvers. Adoption among the large public resolvers is good; adoption across all resolvers is partial. A signed zone protects the fraction of users whose resolver validates.
- Anything that depends on DNSSEC to work at all. DANE for SMTP requires it. Some registry lock arrangements assume it.
- You, against a specific and serious attack. Traffic redirection via forged DNS answers is not the most common attack in this course, and it is among the most complete when it happens.