Your domain says it's DNSSEC-signed. Validating resolvers say it's broken.

Here's a failure mode that hides from the person who caused it. Your domain is DNSSEC-signed, the signing chain breaks, and from your own machine everything still works. You load the site, mail flows, nothing looks wrong. Meanwhile a large and growing share of the internet, everyone whose resolver actually validates DNSSEC, can't reach you at all. They get a hard SERVFAIL and the domain may as well not exist.

It's a self-inflicted outage, it's fixable, and the cruel part is that the people best placed to notice are the least likely to, because their own lookups skip validation or get cached. The visitors who hit the wall don't email you; they just leave.

What "signed but broken" means

DNSSEC works by signing your DNS records and publishing a chain of trust up to your domain's parent zone. The parent publishes a DS record, a fingerprint that says "this domain is signed, and here's how to verify it." A validating resolver follows that chain, checks the signatures, and only then hands back the answer.

The chain breaks more easily than you'd hope. An RRSIG signature expires and nobody re-signed the zone. A key rollover went halfway and left the published DS pointing at a key that's no longer there. A DNSKEY got removed. When any of that happens, a validating resolver doesn't fall back to "well, I'll serve it anyway." It refuses, because the whole point of validation is that a broken chain is indistinguishable from tampering. The resolver returns SERVFAIL, and the visitor gets nothing.

The resolvers that do this aren't fringe. Cloudflare's 1.1.1.1, Google's 8.8.8.8, Quad9, and a lot of ISP resolvers all validate. So "signed but broken" isn't a rounding error of users, it's a real and rising fraction of your traffic going dark.

Why this fires only on the broken case, never on "no DNSSEC"

The web is overwhelmingly unsigned. Most domains have no DNSSEC at all, and that's a perfectly normal, defensible choice, not a problem. A check that fired on "you don't have DNSSEC" would light up on the majority of the internet, wreck everyone's grade, and read as noise. So this finding says nothing about an unsigned domain. It fires on exactly one situation: a domain that turned DNSSEC on and then broke it.

Pinning that down without false alarms takes three signals, because a transient blip or a plain outage shouldn't trigger it. First, the parent has to publish a DS record, so the domain genuinely claims to be signed. Second, two independent validating resolvers both have to return SERVFAIL for the apex, not one resolver having a bad moment. Third, a plain non-validating lookup still has to succeed, which proves the host itself is up and it's the validation chain that's broken, not that the server is down. All three together mean the same thing: this domain is signed, broken, and dark for validating users. Any timeout, network error, or single-resolver hiccup, and the check stays silent.

It's a medium-severity finding, because it's a real availability problem with a clear fix, not a catastrophic compromise.

Fix the chain, or unsign cleanly

There are two honest ways out, and which one you want depends on whether you meant to run DNSSEC.

parent zone:  DS record present
your zone:    RRSIG expired / DNSKEY mismatch
result:       SERVFAIL on validating resolvers

If you want DNSSEC, fix the chain: re-sign the zone, publish the correct DNSKEY, and finish the key rollover so the published DS matches what's live. If DNSSEC was switched on by accident or you don't want to maintain it, remove the DS record at your registrar to unsign the domain cleanly, which takes you back to a normal unsigned domain that everyone can reach.

Whether validating resolvers can actually reach your domain is something checkable from outside without touching your servers, by reading the same DNS the rest of the internet reads. SurfaceCheckr queries public validating resolvers, looks for the DS-present-plus-SERVFAIL pattern, and confirms the host still resolves on a plain lookup before it says anything, so a one-off blip or a genuinely-down host never trips it. It reports only the signed-but-broken case, because that's the one that's invisible to you and visible to everyone else. That's the outage you find from your statement, not your logs, unless something checks it the way your visitors' resolvers do.

For the DNS records that point at the wrong thing in other ways, see dead MX, private IPs, and dangling nameservers, and for the certificate-authority side of locking down your domain, the CAA record article.