DNSSEC and the chain of trust
Everything you have learned about DNS so far has a hole in it. Nothing in a plain DNS answer proves who wrote it. A response is a UDP datagram with a matching query id, and anybody positioned to send one first has effectively answered your question.
DNSSEC closes that hole — and it is worth being precise about how, because it is routinely misunderstood:
| DNSSEC does | DNSSEC does not |
|---|---|
| Prove an answer came from the zone | Hide the question from observers |
| Prove it was not altered in transit | Encrypt anything at all |
| Prove a name genuinely does not exist | Say whether the site is trustworthy |
It authenticates. It does not encrypt. A signed answer is still perfectly readable by anyone on the path — that is a different problem, solved by DNS over HTTPS.
How the chain is linked
Each zone signs its own records with its own key. The question is why you should believe that key, and the answer is that the parent vouched for it:
root zone DNSKEY <- trusted because it is configured, never looked up | DS <- a hash of .com's key, signed by the root vcom zone DNSKEY <- matches the DS above, so now trusted | DS <- a hash of example.com's key, signed by .com vexample.com DNSKEY <- matches, so now trusted RRSIG <- signature over the actual answerThe DS record lives in the parent and the DNSKEY in the child, at exactly the same place the delegation happens. Validation walks that chain from a root key the resolver already holds — the one link that is configured rather than fetched, because a chain of trust has to start somewhere it cannot be told.
What a validator does when it cannot prove something
A validating resolver that cannot verify a signature does not hand you the data with a warning. It returns SERVFAIL — no answer at all — because passing along data it cannot prove would make the whole exercise pointless.
That is why a DNSSEC misconfiguration takes a domain completely offline for validating users while working perfectly for everyone else, and why it is one of the more alarming ways to break a website.
Key takeaways
- DNSSEC authenticates DNS answers. It does not encrypt them, and it says nothing about whether the site is trustworthy.
- Each zone signs its own records; the parent publishes a DS hash of the child’s key, so trust is chained down the same tree the delegations follow.
- The root key is configured, never looked up — one link has to be established out of band or the chain is circular.
- A validator that cannot prove an answer returns SERVFAIL rather than passing along unverified data.
- That makes DNSSEC failures partial and audience-dependent: a total outage for validating users, invisible to everyone else.