The problem DNSSEC solves
Without DNSSEC, DNS responses are trusted purely because they arrived — there's no signature to check, no way to confirm authenticity. That opens the door to cache poisoning: an attacker forges a fake DNS response and gets a resolver to cache it, redirecting anyone who queries that resolver to a server the attacker controls instead of the real one. This can be used to intercept traffic, harvest credentials on a convincing fake login page, or redirect mail.
DNSSEC doesn't encrypt DNS traffic — that's a separate technology (DNS-over-HTTPS or DNS-over-TLS). What it does is let a resolver cryptographically verify that a response hasn't been forged or altered, using a chain of signatures rooted in the domain's parent zone.
How the chain of trust works
Each DNSSEC-signed zone publishes its records along with a digital signature, generated using a private key that only the zone's operator holds. A resolver checking a response fetches the corresponding public key and verifies the signature. But that alone only proves the signature is internally consistent — it doesn't prove the public key itself is trustworthy.
That's solved by chaining: the parent zone (say, the registry for .com)
publishes a record — a DS record — that's a hash of the child zone's public key. So a
resolver can verify the child zone's key by checking it against the parent's DS record,
verify the parent's key against its own parent, and so on, all the way up to the root
zone, which every validating resolver trusts by configuration. Break any link in that
chain — an expired signature, a missing DS record — and DNSSEC validation fails for the
whole domain.
What DNSSEC doesn't protect against
It's worth being precise about scope, since DNSSEC gets credited with more than it actually does:
- It doesn't encrypt queries or responses. Anyone observing the traffic can still see which domains are being looked up.
- It doesn't protect the "last mile" to the end user's device unless that device is itself performing validation — most consumer devices rely on their resolver to validate and simply trust what comes back.
- It says nothing about a website's content or reputation — a DNSSEC-signed domain can still host a phishing page. DNSSEC only guarantees the DNS response wasn't forged, not that the site is trustworthy.
The most common failure mode
DNSSEC signatures have expiration dates and need to be regenerated periodically. Unlike a TLS certificate expiring — which produces a loud, visible browser warning — an expired DNSSEC signature fails silently from most users' perspective, but causes validating resolvers to refuse to resolve the domain at all, which looks exactly like the domain being down. This makes signature-expiry monitoring worth treating as seriously as certificate expiry monitoring, even though it gets far less attention.