Almost every security control on your stack fails open. Let an HSTS header lapse and the site still loads. Let a CSP go stale and the page still renders. Let a TLS certificate expire and the server still answers — the browser throws a warning the user can click past. The protection degrades; the traffic survives.
DNSSEC is the one that fails closed. When a signed zone's cryptography stops validating, a validating resolver does not shrug and serve the answer anyway — it returns SERVFAIL and refuses to hand back an address at all. There is no padlock warning, no "proceed anyway," no degraded mode. From the client's point of view the domain simply ceases to exist. And because the failure lives in the resolver, not the browser, it hits some people and not others — which is exactly what makes it so hard to catch.
What DNSSEC Actually Promises (and Why Breaking It Is Total)
DNSSEC signs DNS records so a resolver can verify the answer it got came from the real zone and wasn't forged in transit. The chain of trust runs downward: the root signs the TLD, the TLD signs your domain via a DS record held at your registrar, and your zone signs its own records with a DNSKEY, producing an RRSIG signature over each record set. A validating resolver walks that chain from the root to your record. If every link checks out, it sets the AD (Authenticated Data) flag and returns the answer.
If any link fails to validate — not "is missing," but "is present and wrong" — the resolver's only safe move is to return SERVFAIL. That is the design, not a bug: the whole point of DNSSEC is to refuse a forged answer, and a broken signature is indistinguishable, to the resolver, from an attack. So the failure mode of a security feature whose job is to reject bad data is to reject your data.
The blast radius is bigger than the website, too. DNSSEC breakage takes the whole zone with it: the A/AAAA for the site, the MX for mail, every subdomain and API record. It is closer to a domain-registration lapse than a certificate expiry — the name stops resolving, and everything hanging off it goes with it.
Why It Breaks: Signatures Have Their Own Clock
The trap in DNSSEC is that it adds a third expiration clock to your domain, independent of the two people already forget. Your TLS certificate expires. Your domain registration expires. And now your RRSIG signatures expire — every signature carries its own validity window (often a few weeks), and the zone has to re-sign before they lapse. The common failure paths:
- A key rollover where the parent DS no longer matches the child DNSKEY. This is the number-one cause. You rotate your signing key (or your DNS provider does, or a migration does), the new DNSKEY is published, but the DS record at the registrar — which lives at the parent, in a different system you may not control — still points at the old key. The chain snaps at exactly the link that spans two vendors.
-
Expired RRSIGs. The signer that re-signs the zone stops running — a broken pipeline, a provider change, a manual zone that nobody re-signed after an edit — and the signatures age out. The records are still there; their signatures are just past
notAfter. - Moving DNS providers with signing enabled. You migrate the zone to a new provider, the records come across, but the DNSSEC chain doesn't — the old signatures don't match the new provider's keys, and the DS at the registrar still trusts the old chain.
-
An edit that wasn't re-signed, or an algorithm the resolver won't accept. Any change to a signed record that isn't followed by a valid signature is a
SERVFAILwaiting for the cache to expire.
Note what's not on that list: an attacker. The overwhelming majority of DNSSEC outages are self-inflicted operational breakage, not intrusions — which is its own argument for watching it.
Why You Can't Reproduce It: "It Works for Me"
Here is the part that turns a DNSSEC outage into a multi-hour incident. Not every resolver validates. When your zone's signatures break:
- Anyone using a validating resolver — Cloudflare's
1.1.1.1, Google's8.8.8.8, Quad9's9.9.9.9, and most large ISP resolvers today — getsSERVFAIL. The site is down for them, hard. - Anyone using a non-validating resolver, or hitting a cached answer that hasn't expired yet, resolves the domain perfectly. It works, exactly as before.
So the reports are contradictory and maddening: half your users say the site is down, half say it's fine, and you — on the office resolver, with a warm cache — see nothing wrong. curl from your laptop succeeds. The uptime check on a non-validating monitor stays green. Meanwhile a large, invisible slice of the internet is getting a hard failure. The one-line test that cuts through it:
dig +dnssec @1.1.1.1 example.com
Query a validating resolver explicitly and read the flags. A healthy signed zone comes back with the ad flag in the header and RRSIG records alongside the answer. A broken one comes back SERVFAIL from 1.1.1.1 while dig @<a-non-validating-resolver> example.com still returns the address — and that split is the diagnosis. For the full chain, delv example.com does end-to-end validation and tells you which link failed, and dnsviz.net draws the whole chain with the broken edge highlighted.
The Opposite Failure: The Silent Downgrade
There is a second DNSSEC failure that is quieter and arguably worse, because it produces no outage at all. Instead of breaking, the zone gets unsigned — the DS record is removed at the registrar, or signing is switched off, or a migration drops DNSSEC entirely. Now the zone resolves fine for everyone, with the protection silently gone. Nothing pages, because nothing is down. You have simply stopped being protected against DNS forgery, and the only way you'd ever know is if you were watching the posture rather than the uptime.
This is the case an uptime check can never catch, because there is nothing down to catch. A signed → unsigned transition is a security regression that looks identical to a healthy day. It has to be monitored as a change in state, not as a failure.
TLSA/DANE and CAA Live Next Door
Two related records ride on the same DNS-security surface and are worth checking while you're in there. TLSA (DANE) records — at _443._tcp.yourdomain — pin your TLS certificate through DNS instead of the CA system, and are only meaningful when the zone is DNSSEC-signed (an unsigned TLSA record is unauthenticated and ignorable). CAA records constrain which certificate authorities may issue for your domain, and they inherit down the name tree per RFC 8659, so the effective policy on a subdomain isn't always what you set at the apex. Neither is DNSSEC, but both are part of the same "is my domain's DNS security posture what I think it is" question.
How to Watch It — All Three Clocks
The through-line of every DNSSEC outage is that the signal was knowable and nobody was reading it. So:
- Watch the DNSSEC posture from a validating resolver, continuously — not "is the site up," but "does the AD flag still come back, and did a signed zone quietly go unsigned." A monitor has to distinguish a transient resolver hiccup (which must never fire an alert) from a real signed → unsigned regression, or it becomes noise you'll mute.
- Track the RRSIG expiry the way you track certificate expiry, because it is the same class of problem: a dated artifact that lapses on a schedule and takes the domain with it when it does.
- Verify the DS-at-parent matches the DNSKEY-at-child after every key change, since that cross-vendor seam is where rollovers break.
I work on Merlonix, which reads your domain's DNSSEC and TLSA/DANE posture through Cloudflare's validating resolver on every check, and — because a continuous monitor must not cry wolf on a DoH hiccup — records an authoritative reading only when the resolver actually answers, then alerts specifically on the low-noise signal that matters: a zone that was signed going unsigned, the silent downgrade an uptime check can't see. It walks the CAA inheritance chain in the same pass.
You can check any domain's live DNSSEC, TLSA, SSL, and DNS posture right now without signing up, and the free tools hub has the rest. DNSSEC is the sibling clock to the two most teams already lose sleep over — an expired certificate and an expired domain — with a failure mode nastier than either: it doesn't warn, it doesn't fail open, and it doesn't fail for you.
The certificate that expires gives you a warning page. The domain that expires gives you NXDOMAIN. The DNSSEC signature that breaks gives you a SERVFAIL that half the internet sees and you don't — which is the whole reason it has to be watched from the outside, on a validating resolver, before the cache that's hiding it from you expires.
