DNSSEC Basics: Chains of Trust Without the Panic

DNSSEC has a reputation problem. It is described as essential, then described in terms of cryptography, and then everyone quietly moves on to something easier. The result is a large number of operators who know they "should" enable it and a smaller number who actually understand what it changes.

The honest summary is this: DNSSEC lets a resolver prove that an answer it received is the answer the zone owner actually published, and that nobody tampered with it on the way. That is genuinely valuable. It is also narrower than most people assume, and the failure modes it introduces are worth understanding before you turn it on.

What DNSSEC does, and what it does not

DNSSEC adds signatures. Every set of records in a signed zone has a matching cryptographic signature, and a validating resolver checks that signature before it accepts the answer.

Three things follow from that, and one important thing does not.

DNSSEC protects integrity: a resolver can detect that an answer was modified in transit. It protects authenticity: the answer can be traced back to a key that the zone's parent vouched for. And it can prove non-existence: a signed zone can cryptographically demonstrate that a name really does not exist, rather than simply saying so.

What it does not do is provide privacy. Signed answers are not encrypted. Anyone watching the wire still sees every query and every response. DNSSEC prevents tampering, not observation — if you want privacy you are looking for DNS over HTTPS or DNS over TLS, which are entirely separate mechanisms.

The chain of trust, one link at a time

The interesting part of DNSSEC is how a resolver decides to trust a key it has never seen before. The answer is that trust is delegated downwards.

Start at the root. The root zone is signed, and its key is widely known — it is the trust anchor that ships with validating resolvers.

Now suppose your zone is example.com. For a resolver to trust your signatures, it needs a link between .com and you. That link is a DS record: a small record published in the parent zone (.com) that contains a fingerprint of your key-signing key. Because .com is signed and the root vouches for .com, and .com vouches for your key, a resolver can walk the chain from the root all the way to your zone.

That chain is only as strong as its weakest — and, more importantly, most fragile — link. If the DS record in the parent does not match the key material in the child, the chain breaks and the zone effectively disappears for validating resolvers, even though it still works fine for everyone else. This single fact is the cause of most DNSSEC outages.

The four record types worth knowing

DNSKEY holds the zone's public keys. There are normally two: a key-signing key, which signs other keys, and a zone-signing key, which signs the actual records. Separating the two is what allows you to rotate the frequently-used key without touching the delegation.

RRSIG is a signature. It accompanies an answer and covers that record set, with a validity period and an inception date.

DS lives in the parent zone and points at a child's key-signing key. It is the link in the chain.

NSEC and NSEC3 prove that a name does not exist. NSEC does it by listing the names that do exist, which has the side effect of letting anyone enumerate every name in your zone. NSEC3 avoids that by hashing the names, at some cost in size and complexity.

Why validating resolvers behave differently

Not every resolver validates. Many forwarders and older appliances simply fetch answers and pass them along, and they will happily return a tampered or broken answer.

Validating resolvers check the chain. When the chain holds, nothing changes from your perspective — the answer looks identical. When the chain is broken, the resolver refuses to pass along an answer it cannot verify, and returns SERVFAIL instead.

That is the correct behaviour, and it is also the source of the split-brain experience that makes DNSSEC scary. Half your users get your site; half get a resolver error. The half that gets an error is not wrong, and the half that gets the site is not "working" — it is merely unvalidated.

The split-brain outage, explained

Here is the scenario in its most common form.

You rotate your zone-signing key in the child zone. The zone still validates internally, and non-validating resolvers keep working, so from your monitoring everything looks fine. But the DS record in the parent still points at the old key-signing key, or the new ZSK has not yet propagated, or the DS update was submitted but the parent has not published it.

Validating resolvers now see a zone whose DS does not match its DNSKEY set. They return SERVFAIL — for everyone, on every record type, including the records that have nothing to do with the rollover.

The lesson is not that DNSSEC is dangerous. It is that DNSSEC failures are global and total, rather than partial, and that the parent-side DS is the piece people forget because it lives in a different console from the zone they are editing.

Rolling keys without breaking anything

The safe pattern for key rollovers is overlap. You publish the new key alongside the old one, and both are valid at the same time.

In practice: publish the new key material, wait at least one full TTL period plus the time your parent takes to publish a DS change, update the DS at the parent, wait again for that to propagate, and only then remove the old key. Never replace a key in place. A key that exists on both sides of the transition is safe; a gap where neither matches is an outage.

Signatures have validity windows too, and this is a quieter trap. If your signer stops refreshing them — a cron job that fails, an API credential that expires — records keep working until their signatures lapse, and then the zone goes dark for validators all at once. Monitor signature expiry the way you monitor certificate expiry, because it fails the same way: silently, until it does not.

Checking a zone without being a validating resolver

You do not need to run a validator to get useful visibility. You can ask for the DS record at the parent and the DNSKEY set in the zone, and compare what you get.

If there is no DS at the parent, the zone is unsigned from the world's point of view, whatever your panel says. If there is a DS and the DNSKEY set does not contain the key it fingerprints, you have found a broken chain. If both are present and consistent, the remaining questions are about signature validity windows and algorithm support.

Treat that as a smoke test rather than an audit. It catches the mistakes that cause outages — a missing DS, a mismatched key, an unsigned child — without pretending to be a full validating resolver. Try it on DNS Checkers Lookup All DNS Records

When not to enable DNSSEC

DNSSEC is the right default for zones you control carefully. It is worth pausing before enabling it on a domain where the DNS is partly managed by someone else: a marketing team with API access, a third-party platform that writes records for you, a registrar whose interface you use twice a year.

Every one of those becomes a potential source of a broken chain, and a broken chain does not degrade gracefully — it takes the whole zone down for a meaningful share of the internet. If you cannot confidently control both the parent DS and the child keys, DNSSEC raises your risk rather than lowering it.

For a domain where DNS is a critical dependency and the operational ownership is clear, enable it. For a side project on a shared platform with no DS support at all, the honest answer is often "not yet".

The mistakes that cause outages

Almost every DNSSEC incident comes from a short list. Rolling a key in place instead of overlapping. Updating the child but not the parent. Updating the parent before the child has published the new key. Letting signatures expire because a cron job was silently failing. Enabling DNSSEC at a provider that signs, then moving to a provider that does not, without turning it off first.

Every one of those is a sequencing error rather than a cryptography error. Which is good news: sequencing is something you can write down, review, and rehearse in a staging zone — and that is exactly what you should do before touching a production domain.

The short version

DNSSEC signs your records and chains the trust back to the root, so a validating resolver can refuse an answer it cannot verify. The parent DS is the fragile link, key rollovers must overlap rather than replace, and failures are total rather than partial for anyone who validates.

Understand those three sentences and you understand the operational reality of DNSSEC. The cryptography is somebody else's problem — your problem is the order in which you publish things.