DNSSEC Explained: What It Protects Against (and What It Doesn't)

DNS was designed without any way to verify that a response actually came from the nameserver it claims to, or that it wasn't altered along the way. A resolver asking "what's the A record for example.com" has no built-in way to know the answer it gets back is genuine. DNSSEC (Domain Name System Security Extensions) closes that gap with cryptographic signatures, at the cost of being one of the more operationally fragile things you can add to a domain.

The problem DNSSEC solves

Without DNSSEC, a resolver trusts whatever answer it receives, as long as it appears to come from the right place and matches the query. That trust is exploitable. Cache poisoning is the classic attack: an attacker races to inject a forged response into a resolver's cache before the legitimate answer arrives, causing every subsequent query for that name to return the attacker's forged data (routing traffic to a server they control) until the poisoned entry's TTL expires. This doesn't require compromising the domain's actual DNS provider at all. It exploits the resolver's inability to tell a genuine answer from a forged one.

DNSSEC adds a way to verify authenticity: every response can be checked against a cryptographic signature, so a forged answer, even one that arrives at exactly the right moment with exactly the right structure, fails verification and gets rejected.

The chain of trust, in order

DNSSEC works by signing records and then signing the signatures' validity all the way up to the root, so a resolver validating a response doesn't have to blindly trust any single point in the chain.

RRSIG records hold the actual cryptographic signature for a set of records. Every signed record type in your zone (A, MX, TXT, and so on) gets a corresponding RRSIG covering it.

DNSKEY records publish the public keys used to verify those signatures, at the zone itself. There are typically two: a Zone Signing Key that signs the everyday records, and a Key Signing Key that signs the DNSKEY record set itself.

DS records live in the parent zone (published by your registrar, at the TLD level) and contain a hash of your zone's Key Signing Key. This is the link that connects your zone's keys to a parent that's already trusted, which is what makes the whole thing a chain rather than an isolated, self-asserted claim.

Validation walks this chain from the root down: the root zone's keys are trusted by definition (built into resolver software), the root vouches for the TLD's DS record, the TLD vouches for your DS record, and your DS record vouches for your DNSKEY, which in turn validates every RRSIG in your zone. Break any link and validation fails for everything below it.

What a signed zone looks like

example.com.       IN  DNSKEY  257 3 8  AwEAAcaB...
example.com.       IN  RRSIG   DNSKEY 8 2 3600 ...
example.com.       IN  A       203.0.113.42
example.com.       IN  RRSIG   A 8 2 3600 ...

You can query for these directly:

dig DNSKEY example.com
dig +dnssec A example.com

The +dnssec flag on the second query requests the RRSIG alongside the answer, which is what a validating resolver checks against the published DNSKEY.

Enabling DNSSEC on a domain

DNSSEC requires coordination between your DNS provider and your registrar, which is what makes it more involved than adding a record:

1. Your DNS provider signs your zone, generating the DNSKEY and RRSIG records automatically. Most managed providers handle key generation and rotation without any manual involvement once enabled.
2. You publish a DS record at your registrar, using the values your DNS provider gives you for exactly this purpose. This is the step that actually plugs your zone into the parent's chain of trust; without it, your zone is signed but nothing above it vouches for those signatures, so validation simply doesn't happen.
3. Validating resolvers pick it up automatically once the DS record is live and has propagated. There's no separate opt-in on the resolver side for a domain that's correctly configured; if a resolver validates DNSSEC at all, it validates it for every signed domain it queries.

What breaks it

A stale DS record after a DNS provider migration. If you move DNS providers and don't update the DS record at your registrar to match the new provider's keys, validating resolvers will reject every response for your domain outright once the mismatch is detected. This is one of the few DNS misconfigurations that causes total, hard failure rather than degraded behavior: a domain with a DS record that doesn't match its DNSKEY doesn't intermittently fail, it stops resolving for anyone using a validating resolver.

Key rotation without updating the DS record. Zone signing keys are typically rotated automatically by your provider without requiring a DS update, since the DS record hashes the Key Signing Key rather than the everyday signing key. But a Key Signing Key rotation does require a corresponding DS record update, and providers vary in whether that's automatic or something you need to trigger.

Disabling DNSSEC in the wrong order. Removing your signed records before removing the DS record at your registrar leaves a DS record pointing at keys that no longer exist, which causes the same hard failure as a stale migration. The DS record has to come down first, or after propagation of removing signing, not before.

What DNSSEC does not protect against

This is the part that gets conflated most often. DNSSEC verifies the authenticity and integrity of a DNS response. It does not:

• Encrypt DNS queries or answers. Anyone observing the traffic can still see what domain was looked up and what the answer was. That's a separate concern, addressed by DNS-over-HTTPS or DNS-over-TLS, which encrypt the query in transit but don't provide the authentication chain DNSSEC does.
• Protect anything after the DNS lookup completes. DNSSEC has nothing to do with whether the server at the resolved IP address is running a valid TLS certificate, or whether that server is trustworthy. A domain can have perfect DNSSEC and still be compromised at the hosting level.
• Stop an attacker who already controls your DNS provider account. If someone has legitimate access to change your records, they can sign whatever they change with your own keys. DNSSEC authenticates that a response matches what your provider published; it doesn't evaluate whether what got published was itself authorized.

DNSSEC is specifically an answer to "can I trust that this response wasn't forged in transit or by a compromised resolver." It's not a general DNS security product, and it doesn't reduce the importance of monitoring your actual record values, which is a different problem: whether the authoritative answer itself is correct, regardless of how faithfully it was delivered.

How DNS monitoring fits in

DNSSEC and record monitoring solve adjacent but different problems. DNSSEC lets a resolver trust that a response genuinely came from your provider, unaltered. Monitoring tells you whether what your provider is publishing is actually what you intended. A DS record mismatch after a migration, or a DNSSEC-related outage, still shows up as a records issue worth knowing about immediately, and OneDollarDNS monitors your zone's actual record values and nameserver responses directly, independent of whether DNSSEC validation is involved in how a given resolver reaches that answer.