Plain DNS answers come with no proof. DNSSEC adds digital signatures so a resolver can check that an answer really came from the zone owner and wasn’t changed on the way.

How the signatures work

A signed zone publishes its public keys in DNSKEY records. Every set of records gets a signature, stored in an RRSIG record.

A validating resolver checks the signature against the data and against a key it trusts. If they match, the answer is authentic. If they don’t, something forged or altered it.

The records stay readable by anyone. DNSSEC proves authenticity, not secrecy.

The chain of trust

How does the resolver know which key to trust for example.com? The parent zone vouches for it.

The .com zone publishes a DS record for example.com, a hash of the child’s key. The root does the same for .com. The resolver starts from the root key it ships with, the trust anchor, and follows DS records down to the zone it’s checking.

Three outcomes

Each validated answer lands in one of three buckets:

secure: the signatures validate all the way up the chain
insecure: the zone isn’t signed, and the parent proves there’s no DS for it
bogus: the chain says this should validate, and it doesn’t

Bogus answers reach your application as SERVFAIL. That’s on purpose. The resolver refuses to hand out data it can’t authenticate. Insecure is fine. Bogus is an alarm.

Look at the records

Let’s see the DNSSEC data for a signed domain:

dig +dnssec A cloudflare.com
dig +dnssec DNSKEY cloudflare.com
dig DS cloudflare.com

+dnssec asks the server to include RRSIG records in the response. It doesn’t make dig validate anything itself.

Look for the ad flag in the header. It means the resolver you asked considers the answer authenticated. That flag is only worth something if you trust the path to that resolver.

What DNSSEC does not do

It doesn’t encrypt your queries. It doesn’t hide record contents. It doesn’t protect an unsigned zone, keep your nameservers online, or make the website behind the name safe.

It authenticates DNS data. Full stop.

Deployment order

Turn on signing at your DNS host and confirm the zone validates. Only then publish the DS record through the registrar.

When you move providers or turn DNSSEC off, reverse the order: remove the DS first, wait for caches, then change the zone. A stale DS makes every validating resolver return SERVFAIL for your whole domain, while your own tests on a non-validating resolver look fine.

Try this: query one signed and one unsigned domain through 1.1.1.1, which validates. Note the RRSIG, DNSKEY, DS, and ad evidence for each, then explain why the unsigned answer is insecure, not bogus.

What DNSSEC protects