DNSSEC Explained: Chain of Trust and Failures

By Bill Hartzer, domain name expert and expert witness·August 10, 2026

What DNSSEC Actually Proves

DNSSEC is a set of cryptographic signatures added to DNS records so a resolver can prove the answer it received genuinely came from your zone and was not forged in transit. That is the whole claim, and the precision matters: it is an authenticity control over answers, not an ownership control over registrations.

RFC 4033, the introduction and requirements document published in March 2005, defines the machinery. Four record types do the work — RRSIG (the signature attached to a set of records), DNSKEY (the public half of the key your zone signs with), DS or Delegation Signer (a hash of your zone's key, published by the registry in the parent zone), and NSEC (which proves a name does not exist). Two message header bits accompany them: CD, checking disabled, and AD, authenticated data.

Validation is performed by what the RFC calls a security-aware resolver — one supporting the EDNS0 message size extension and the DO bit. A resolver without those ignores DNSSEC entirely. That asymmetry explains most of the confusion during a DNSSEC incident, when a domain is unreachable for a large fraction of the internet while working perfectly for whoever is testing it.

The Chain of Trust, Link by Link

Every set of records in a signed zone is signed with the zone's private key, the signature published as an RRSIG and the matching public key as a DNSKEY. On its own that proves nothing — anyone can sign anything with a key they made up. What makes it meaningful is the chain.

RFC 4033 describes it as “an alternating sequence of DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets” forming “a chain of signed data, with each link in the chain vouching for the next.” Concretely, for a .net domain:

The root zone's key is a trust anchor — defined in RFC 4033 as a configured DNSKEY record or DS hash that the validator trusts inherently, without needing anything above it.
The root publishes and signs a DS record for .net, vouching for the .net registry's key.
The .net registry publishes and signs a DS record for your domain, which is a hash of your zone's key-signing key.
Your zone's key-signing key vouches for the zone-signing key that signs your everyday records.

Break any link and everything below it fails validation. Notice where the links live: the DS record for your domain sits in the parent zone, published by the registry and normally changeable only through your registrar. DNSSEC is a DNS-layer control with a registry-layer control point, which is why it interacts so badly with registrar transfers.

A signed zone whose parent publishes no DS is what RFC 4033 calls an island of security: signed, delegated, and with no authentication chain from its parent. It gets no validation benefit — and, usefully, no failure mode either.

Fail-Closed Is the Design, Not a Bug

When a validating resolver cannot verify the chain, it does not fall back to the unsigned answer. It returns SERVFAIL. To the user that looks like the site does not exist — no certificate warning, no partial page, nothing to click through.

This is deliberate and correct for an authenticity protocol, since a fail-open validator would be trivially defeated by breaking validation. It also means a DNSSEC misconfiguration is not a degradation. It is an outage — one that presents for some users and not others depending on whose resolver they use.

State the consequence flatly. Signing a zone converts a class of silent risk into a class of loud, self-inflicted risk. That trade is usually worth making — but not by clicking a button at a registrar without first establishing who signs, who re-signs, and who rolls the keys afterward.

What DNSSEC Does Not Protect

DNSSEC gets counted as an anti-hijacking control in security reviews with some regularity. It is not one.

An attacker who takes over your registrar account does not need to defeat any signature. They remove the DS record at the parent through the registrar interface, wait out its cache lifetime, point the domain at their own nameservers, and — if they want — sign the new zone with their own keys. Validation then succeeds, cleanly, against an attacker-controlled configuration. Nothing in DNSSEC asserts anything about who is entitled to hold the registration.

Nor does it protect the contents of your zone against someone who has your DNS provider credentials. If they can edit records, they can edit signed records, and the signer will faithfully sign whatever they put there.

Where DNSSEC genuinely earns its place, besides on-path forgery and cache poisoning, is as a dependency for other controls. Under the CA/Browser Forum Baseline Requirements, a certificate authority may treat a failed CAA lookup as permission to issue only if — among other conditions — the domain's zone has no DNSSEC validation chain to the ICANN root. In other words, DNSSEC is what makes an absent or unanswered CAA record authoritative rather than merely missing. Without it, an attacker who can suppress your CAA lookup gets the certificate issued anyway.

The Ways People Break It

The failure modes are well-worn and almost entirely self-inflicted.

Transferring a signed domain without dealing with the DS first. The new host serves the zone with different keys; the old DS in the parent still points at the old key; validating resolvers SERVFAIL the domain. This is the most common DNSSEC outage in registrar transfers by a wide margin.
Removing the DS and moving in the same hour. Validators hold the old DS until its cache lifetime expires; the change is not safe to rely on until then.
Letting RRSIGs expire. Signatures carry explicit inception and expiration timestamps, defined in RFC 4034. When a signer job stops quietly, nothing looks wrong until the signatures age out and the zone fails validation with no change made to it. This is the most common cause of self-inflicted DNSSEC outages.
Changing signing algorithm mid-migration. A zone in a multi-operator state must be signed with every algorithm in use.
Assuming it is not DNSSEC because it works for you. If your own resolver does not validate, the domain looks fine from your desk while it is dark for everyone behind a validating one.
Enabling it without assigning ownership. A one-click signing button creates a standing obligation to re-sign and roll keys, and “the registrar probably handles it” is not an answer anyone should accept without checking.

Moving a Signed Domain Without Going Dark

There are two defensible approaches, and the choice should be made explicitly as step one of the runbook rather than discovered halfway through.

The simple path: unsign, then move. Remove the DS record at the registrar first, wait out its cache lifetime so no validator still holds it, then move the domain or the DNS hosting, then re-sign and publish a new DS at the destination. The domain is unprotected during that window but never broken. For most organizations this is the correct choice, and keeping the DS record's cache lifetime low ahead of a planned change shortens the exposure.

The chain-preserving path. This requires that both DNS operators support importing each other's DNSKEY records and that the parent accepts multiple DS records. The order of operations matters:

Stop automated key rotation at both operators.
Create the new signed zone and import the unsigned zone data into it.
Exchange DNSKEY records between the two operators, with the zone signed using every algorithm in use.
Add the new DS record alongside the old one at the registrar — both present at once.
Wait for the parent's NS and DS cache lifetimes to expire.
Change the nameserver delegation.
Wait again.
Remove the old DNSKEY records, and only then remove the old DS.

A zone can safely leave this multi-operator state after about a week and should not sit in it for more than a month or two. Where registrar and registry support them, CDS and CDNSKEY records — defined in RFC 8078 and RFC 7344 — let the child zone signal a DS change to the parent automatically, removing the step where a human pastes a hash into a form and mistypes it.

The .de Outage and What It Demonstrates

On 5 May 2026, DENIC, the registry operator for .de, began publishing incorrect DNSSEC signatures for the .de zone during a routine, scheduled key rollover, starting at approximately 19:30 UTC. Signatures that could not be validated were generated and distributed. Every .de domain became unresolvable for users behind validating resolvers. Cloudflare mitigated the effect on its own resolver at 22:17 UTC by marking .de insecure — a negative trust anchor — giving roughly three hours of impact, cushioned at the start by continuing to serve cached records past their expiry.

It is the cleanest available illustration of fail-closed behavior at scale. Nothing was hacked. No individual domain was misconfigured. A single signature at the TLD level did not verify, and an entire country-code namespace went dark for a large fraction of its users.

Earlier incidents make the same point on a smaller scale: a signing error at nasa.gov in January 2012 caused Comcast's validating resolvers to refuse the domain, and an HBO NOW misconfiguration in March 2015 made the service unavailable on Comcast's networks until corrected. In each case the domain was fine for anyone whose resolver did not validate, which is what makes these incidents slow to diagnose.

Operating a Signed Zone Sensibly

Signing is not the hard part. Continuing to be signed correctly, indefinitely, is.

Decide who signs — registrar, DNS host, or you — and confirm in writing that the same party rolls keys and re-signs on a schedule.
Prefer CDS and CDNSKEY automation where both registrar and registry support it, so DS updates are not gated on manual transcription.
Monitor from outside. Validate the chain from a genuinely validating resolver rather than from your own network, and alarm on approaching RRSIG expiry rather than on SERVFAIL after the fact. By the time you are alerting on SERVFAIL, you are alerting on an outage.
Make DS status a checklist item in every registrar transfer and DNS migration runbook, checked before anything else begins.
Keep the DS record's cache lifetime low ahead of any planned change, so the waiting window is short.
Treat DS presence as a monitored signal. A DS record disappearing that you did not remove is worth investigating on the same day.

Frequently Asked Questions

Will DNSSEC stop someone from stealing my domain?

No. DNSSEC authenticates the answers your zone gives; it says nothing about who is entitled to hold the registration. An attacker with your registrar account removes the DS record at the parent, waits out its cache lifetime, repoints the domain at their own nameservers, and can re-sign the zone with their own keys. Validation then succeeds against their configuration. The controls that address theft are registrar and registry locks plus account security, not DNSSEC.

Why did my domain break for some people and not others?

Because only security-aware resolvers validate. RFC 4033 defines these as resolvers supporting the EDNS0 message size extension and the DO bit; a resolver without them ignores DNSSEC entirely and returns the answer regardless. So a broken chain produces SERVFAIL for users behind validating resolvers — historically certain ISPs and the large public resolvers — while everyone else sees a working site. If a domain is unreachable for a specific subset of users after a DNS or registrar change, check the DS record first.

What is a DS record and why does it live at the registry?

The DS, or Delegation Signer, record is a hash of your zone's key-signing key, published in the parent zone rather than in yours. That placement is the point: a record inside your own zone could be forged along with everything else, so the vouching has to come from above. For a .com domain the DS sits in the .com zone, published by the registry, and is normally changed only through your registrar. That dependency is why registrar transfers and DNSSEC interact badly.

Should I turn DNSSEC on at my registrar with the one-click button?

Only after establishing who is responsible for re-signing and rolling keys afterward. Signing converts a quiet risk into a loud one: a signed zone whose signatures expire goes dark for validating users with no change having been made to it, and expired RRSIGs are the most common cause of self-inflicted DNSSEC outages. If the answer to “who re-signs this zone, and how would anyone know if the signer stopped” is unclear, resolve that before turning it on rather than after.

How do I move a signed domain to a new registrar safely?

The simple path is to unsign first: remove the DS record at the current registrar, wait out its cache lifetime so no validator still holds it, then transfer, then re-sign and publish a new DS at the destination. The domain is unprotected during that window but never broken. The chain-preserving alternative keeps both DS records published at once while the delegation moves, requires both operators to support DNSKEY import and matching algorithms, and needs automated key rotation stopped at both ends.

What should DNSSEC monitoring actually alert on?

Approaching RRSIG expiry, from outside your own network, using a resolver that genuinely validates. That is the alert that gives you time to act. Also alert on the DS record at the parent appearing or disappearing when you did not change it, since DS removal is both a legitimate migration step and something an attacker with registrar access would do first. Alerting only on SERVFAIL means your monitoring tells you about outages rather than preventing them.