What DNSSEC protects, and what it does not
DNSSEC — the DNS Security Extensions — attaches cryptographic signatures to the records in your zone so that a resolver can prove the answer it received genuinely came from you and was not forged or altered in transit. That is the entire promise. It protects the answers, not the ownership.
That distinction is the one people get wrong most often, and it is expensive. An attacker who compromises your registrar account does not have to defeat any cryptography. He removes the DS record — the hash of your zone's key that the registry publishes in the parent zone, the link that anchors your domain to the global chain of trust — waits out the cached copies, and re-points the domain to his own nameservers with a clean, unsigned, entirely valid delegation. Registration-level takeover is a registrar and registry problem, and it is answered with transfer locks and registry lock, not with signatures.
What DNSSEC does answer is the class of attack in which someone lies to a resolver about your records: cache poisoning, on-path tampering, a rogue answer injected between your authoritative server and the user. It is also, by a wide margin, the domain control most likely to take your own site down with no attacker involved at all.
How the chain of trust is built
DNSSEC adds four record types and two message header bits. DNSKEY is the public half of the key pair your zone signs with. RRSIG is the signature attached to a set of records. DS (Delegation Signer) is a hash of your key-signing key, published by the registry in the parent zone. NSEC, and its hashed variant NSEC3, proves that a name does not exist without letting anyone enumerate your whole zone. The header bits are CD (Checking Disabled) and AD (Authenticated Data). All of it is specified in RFC 4033 and its companions RFC 4034 and RFC 4035, published March 2005.
The structure is deliberately plain. RFC 4033 describes it as an alternating sequence of DNSKEY RRsets and DS RRsets forming a chain of signed data, "with each link in the chain vouching for the next." The root zone's key is the trust anchor — the key a validator trusts inherently, defined in the RFC as "a configured DNSKEY RR or DS RR hash of a DNSKEY RR." The root signs a DS for .net; the .net registry signs a DS for the domain beneath it; that DS is a hash of that domain's key-signing key. Break any link and everything below it fails.
Only a security-aware resolver — one that "supports the EDNS0 message size extension and the DO bit" — walks the chain. A non-validating resolver ignores DNSSEC completely, which explains the most confusing symptom in this area: a broken domain is dead for some users and perfectly fine for others. A signed zone whose parent publishes no DS is what RFC 4033 calls an island of security, "a signed, delegated zone that does not have an authentication chain from its delegating parent." It gets no validation benefit — and, importantly, no failure mode either.
Fail-closed: the .de outage of 5 May 2026
DNSSEC does not degrade gracefully. A validating resolver that cannot verify the chain does not quietly fall back to the unsigned answer. It returns SERVFAIL, and to the user the site simply does not exist. The clearest demonstration of what that means at scale happened on 5 May 2026, at the level of an entire country-code top-level domain.
DENIC, the registry operator for .de, started publishing incorrect DNSSEC signatures for the .de zone from approximately 19:30 UTC during a routine, scheduled key rollover; non-validatable signatures were generated and distributed. Every .de domain — every one, regardless of how carefully its own operator had configured anything — became unresolvable for users behind validating resolvers. Cloudflare mitigated the outage on its own resolver by marking .de insecure, a negative trust anchor, at 22:17 UTC: roughly three hours of impact. Cloudflare noted that its practice of serving stale cached records past TTL expiry cushioned the initial impact.
Read what did not happen there. Nothing was hacked. No registrant misconfigured anything. No zone file was wrong. One signature failed to verify during a routine key change, and a national namespace went dark for validating users. That is the risk profile you accept when you sign.
Smaller versions are well documented. A DNSSEC signing error at nasa.gov in January 2012 caused Comcast's validating resolvers to refuse to resolve the domain, and Comcast published a detailed post-mortem. HBO NOW was unavailable from Comcast networks in March 2015 for the same class of reason.
Moving a signed domain without breaking it
The most common self-inflicted DNSSEC outage is a registrar transfer or DNS host change performed as though the zone were unsigned. The new operator serves the zone with its own keys, the DS still sitting in the parent points at the old key, and validating resolvers SERVFAIL the domain. Google's migration guidance for signed zones warns that failing to coordinate the move with both the DNS operator and the registrar ends with validating resolvers "treating the domain as invalid."
There are two ways through, and choosing between them belongs at step one of the runbook.
Unsign first. Remove the DS at the registrar, wait out the DS TTL so that no validator still holds a cached copy, then move. The domain is unprotected for that window but it is never broken. This is the simpler path and the right one for most portfolios.
Preserve the chain. Harder, with real prerequisites: both operators must support importing DNSKEY records and publishing multiple DS records, the zone must use the same signing algorithm at both ends ("zones must be signed with all algorithms in use"), automated key rotation must be halted at both, and you must be able to add a second DS at the parent. The order is stop key rotation, create the new signed zone, import the unsigned zone data, exchange DNSKEY records between operators, add the new DS alongside the old one at the registrar, wait for the parent NS and DS TTLs to expire, change the NS delegation, wait again, remove the old DNSKEYs, and only then remove the old DS. A zone can safely leave that multi-operator state after a week, and should not remain in it for more than a month or two.
Signatures that expire while nobody is watching
RRSIGs carry explicit inception and expiration timestamps. When a signature expires, the zone fails validation even though not one record changed and nobody touched anything. This is the single most common cause of a self-inflicted DNSSEC outage, and its shape is always the same: a signer job stops quietly, nothing looks wrong for days because the existing signatures are still inside their validity window, and then the domain goes dark on a schedule nobody was tracking.
So turning DNSSEC on is not the decision. The decision is who re-signs the zone and rolls the keys afterward, on what schedule, and who gets paged when that stops. A one-click DNSSEC button at a registrar is fine when the answer is "the registrar, automatically, indefinitely." It is a liability when nobody has asked.
Common mistakes
- Transferring a signed domain to a new registrar or DNS host without removing the DS first, so the old DS points at a key the new host does not have.
- Removing the DS and moving in the same hour, without waiting out the DS TTL.
- Concluding the outage is not DNSSEC because "it works for me" — the domain is dark only for users behind validating resolvers, historically particular ISPs and public resolvers rather than everyone.
- Letting RRSIGs expire because a signing job stopped without alerting.
- Changing signing algorithm partway through a migration.
- Turning DNSSEC on at a registrar without establishing who is responsible for re-signing and rolling keys afterward.
- Treating DNSSEC as protection for the registration itself. It is not.
What good practice looks like
- Decide explicitly who signs — registrar, DNS host, or you — and confirm that the same party also rolls keys and re-signs on a schedule.
- Prefer CDS and CDNSKEY automation, defined in RFC 7344 and RFC 8078, where the registrar and registry support it, so DS updates do not depend on a person pasting a hash into a web form.
- Monitor from outside, using a validating resolver, and alarm on approaching RRSIG expiry rather than on SERVFAIL after the fact.
- Before any registrar transfer or DNS host change, check whether a DS exists at the parent and make the unsign-or-preserve decision deliberately.
- Lower the DS TTL in advance of a planned change so the mandatory waiting window is short.
Where a signed zone is already broken, the fix is almost always at the parent — removing or correcting the DS — and that requires the registrar to act. Escalation there is a registration problem, not a DNS one.
DNSSEC is what makes a CAA record enforceable
There is a second, less obvious payoff. Under the CA/Browser Forum Baseline Requirements, a certificate authority may treat a failed CAA lookup as permission to issue only if three conditions all hold: the failure is outside the CA's own infrastructure, the lookup was retried at least once, and "the domain's zone does not have a DNSSEC validation chain to the ICANN root."
Turn that around. If your zone is signed and anchored, an attacker who suppresses or spoofs the CAA lookup cannot count on the CA proceeding anyway; the absence of an answer is not the same as the absence of a record. If your zone is unsigned, or is an island of security with no DS at the parent, that protection does not apply. DNSSEC is what makes an absent CAA record authoritative rather than merely unanswered — which is why the two controls are worth deploying as a pair rather than in isolation.