How DNSSEC Validation Works

When a DNS response arrives at your resolver, how does it know the answer is real? Anyone on the network path could have intercepted the query and sent back a forged response. The domain could resolve to an attacker's server instead of the legitimate one.

DNSSEC transforms this unanswerable question—"who sent this?"—into a verifiable one: who vouches for you?

The Chain of Trust

The DNS root zone sits at the top of every domain name. Your resolver trusts it implicitly—that trust is configured directly into the software. From this single anchor point, trust flows downward through signatures.

The root signs its endorsement of .com. .com signs its endorsement of example.com. And example.com signs its own records. Each endorsement is a cryptographic signature that can't be forged without the private key.

When you query example.com, your resolver doesn't just accept the answer. It traces the chain: Does the root vouch for .com? Does .com vouch for example.com? Does example.com's signature check out? If every link holds, the answer is authentic.

How Signatures Work

Every DNSSEC-signed zone publishes two things: public keys (in DNSKEY records) and signatures (in RRSIG records).

The zone owner uses their private key to sign each set of records. This signature—stored in an RRSIG record—travels alongside the DNS data itself. To verify, the resolver retrieves the zone's public key, uses it to decrypt the signature, and computes its own hash of the received records. If the hashes match, two things are proven: someone with the private key created the signature, and the records haven't been modified since.

But how do you trust the public key itself? A clever attacker could forge both the records and a fake key to sign them.

DS Records: The Link Between Zones

This is where the chain forms. Each parent zone publishes a DS (Delegation Signer) record containing a hash of the child zone's key. The parent signs this DS record with their own key.

Verifying example.com works like this:

1. Check example.com's signature using example.com's public key
2. Verify that key by checking its hash against the DS record in .com
3. Verify .com's key by checking its hash against the DS record in the root
4. Verify the root's key against the trust anchor—the key your resolver was configured to trust

Every link is cryptographically verified. Break any link and validation fails.

What Resolvers Actually Do

DNSSEC-validating resolvers start with one or more trust anchors—public keys they inherently trust, typically just the root zone's key. Everything else must be verified.

When a query arrives, the resolver works top-down. It validates each zone's key before proceeding to the child. Only after the entire chain checks out does it accept the final answer.

Resolvers cache validation states alongside records. Once .com's key is validated, subsequent queries to any .com domain skip that step until the cached key expires. This keeps DNSSEC from adding noticeable latency to most queries.

When Validation Fails

Validation can fail for many reasons: expired signatures, missing records, broken chains, or actual attacks.

A DNSSEC-validating resolver returns SERVFAIL rather than unvalidated data. It would rather give you nothing than give you a lie. If a signed zone can't be validated, something is wrong, and the resolver won't pretend otherwise.

This means misconfigurations can make domains unreachable. If a zone operator forgets to refresh signatures before they expire, validation fails and the domain goes dark until they fix it. The protocol treats "can't verify" the same as "verification failed"—both result in no answer.

DNSSEC-Aware vs. DNSSEC-Validating

Not all resolvers validate. The distinction matters.

DNSSEC-aware resolvers understand DNSSEC record types and can pass them along, but they don't verify signatures. They're capable of handling DNSSEC but don't enforce it. An attacker could send forged responses and these resolvers would cache and serve them without complaint.

DNSSEC-validating resolvers actively verify every signature and chain of trust. They refuse to serve data that fails validation. Major public resolvers like Google (8.8.8.8) and Cloudflare (1.1.1.1) are validating resolvers—they protect everyone who uses them, regardless of whether the client understands DNSSEC.

The security guarantee comes only from validating resolvers. Being DNSSEC-aware without validating is like having a lock on your door but never engaging it.