Each zone signs the one below it. A validating resolver checks every signature from the root down; if any fails, it rejects the answer instead of passing on a forgery.
The short version: encryption keeps your lookups private; DNSSEC keeps the answers honest. They are two different jobs, and DNSSEC is the second one.
What DNSSEC actually is
DNSSEC, short for DNS Security Extensions, is a set of additions to ordinary DNS that let a domain cryptographically sign its records. Each signed answer carries a digital signature the domain produced with a private key only it holds, and a resolver can check that signature against the domain's matching public key. Alter the answer by even one character and the signature stops matching, so the check fails. In short, it adds authenticity and integrity to a system that originally had neither: a way to prove an answer is real and unchanged.
It is worth stating plainly, because it is the most common misunderstanding: DNSSEC signs, it does not encrypt. Your lookups and their answers stay fully readable to anyone on the path. What changes is only that they can no longer be forged without being caught.
Why it is needed
Plain DNS was designed in a more trusting era and has no way to prove an answer is genuine. When a resolver asks for a name and an address comes back, nothing in classic DNS shows whether that address truly belongs to the domain or was slipped in by someone in between. That gap is not theoretical.
The clearest example is cache poisoning. A resolver stores answers briefly so it can reply quickly, so if an attacker manages to inject a forged reply before the real one arrives, the resolver caches the forgery and then serves it to everyone who asks next. Aim that at a domain people rely on, a bank, an email provider, a software update server, and ordinary users are quietly sent to an impostor that looks identical while the address bar still shows the correct name. Passwords are entered, updates are swapped, and nothing appears wrong.
Encryption alone does not close this. Encrypted DNS protects the link between you and your resolver, but it says nothing about whether the records themselves are real. DNSSEC fills that gap: because each record is signed and the signatures chain back to the root, a forged answer simply fails validation, and a validating resolver discards it instead of handing it to you.
How the chain of trust works
Every signed zone holds a key and signs its own records with it, producing a signature record alongside each answer. On its own a signature proves nothing, because anyone can sign anything. What makes it trustworthy is that the parent zone vouches for the child's key: the root vouches for the key of .com, .com vouches for the key of example.com, and example.com signs its own records.
That hand-off mirrors the same hierarchy a resolver already walks to find a name. A validating resolver starts from one fact it trusts absolutely, the root's public key, known as the trust anchor, and follows the chain down. At each step it confirms the parent's vouch for the child, then checks the child's signature on the data. If every link holds, the answer is authentic. If any signature is missing or wrong, the resolver refuses to return it at all rather than serve something it cannot verify.
In record terms you may see these names: the key is published as a DNSKEY, each answer's signature as an RRSIG, and the parent's vouch for the child as a DS record. You never handle these yourself; the resolver does the checking on your behalf.
What DNSSEC does, and does not, do
- Prove an answer came from the real domain
- Detect tampered or forged records
- Defend against cache poisoning and spoofing
- Reject bad answers instead of serving them
- Encrypt or hide your lookups
- Keep your browsing private from the network
- Help with domains that are not signed
- Replace encrypted DNS, it sits beside it
DNSSEC is not encryption
This is the confusion worth clearing up. Encryption and DNSSEC answer two different questions, and a complete setup wants both.
Encrypted DNS
Confidentiality
Answers “who can read my lookups?” DoH, DoT, and DoQ hide the query from the network between you and the resolver. The detail is in the protocol comparison.
DNSSEC
Integrity
Answers “can I trust the reply?” It does not hide anything; it guarantees the answer was not forged or altered. The two are complementary, not alternatives.
Do you need to set anything up?
Mostly no. DNSSEC is two other parties' work: the domain owner signs their zone, and your resolver validates the signatures. Your part is simply to use a resolver that performs that validation, so a forged answer is rejected before it ever reaches you. A resolver that does not validate will happily pass a forgery along, signed or not. If you would rather run that validating resolver yourself, the resolver runbook walks through it.
This service validates DNSSEC in its resolver, Unbound, on every query, so a forged or broken answer never reaches you; the infrastructure page shows that alongside the rest of the setup. Pair a validating resolver with an encrypted protocol from the setup guide and you have both jobs covered: private lookups, and answers you can trust.
Both jobs, together
Encryption keeps your lookups private; DNSSEC keeps the answers honest. Set up one resolver that does both.
Open the setup guide