A DNSSEC failure has a distinctive shape. The domain does not slow down or half-work: it disappears, for everyone using a validating resolver, while continuing to work perfectly for anyone whose resolver does not validate — possibly including you.
The symptom
SERVFAIL, not NXDOMAIN.
That distinction matters. NXDOMAIN means the name does not exist. SERVFAIL on a signed domain usually means a resolver got an answer and refused to use it — most often because validation failed.
It is widely misread as "the nameserver is down". If the nameservers were down you would see a timeout instead.
Confirming it in two commands
Does it fail only when validating?
dig example.com @1.1.1.1
dig +cd example.com @1.1.1.1+cd means checking disabled — it asks the same resolver to skip validation. If the first fails and the second succeeds, it is DNSSEC. That one comparison saves a lot of guessing.
Where does the chain break?
delv example.comdelv validates and reports which step failed. If it is not installed, dig +dnssec example.com and the absence of the ad flag tells you validation did not succeed, without saying why.
The usual causes, in order of likelihood
The DS does not match the zone's key. By far the most common. It happens when a domain was moved to a new provider without removing the DS first, or when a DS was added from the wrong zone, or pasted truncated.
dig +short DS example.comCompare the key tag there against the one on the DNSSEC page. Different tags mean the parent is vouching for a key the zone no longer uses.
The zone was unsigned while the DS was still published. Same effect: resolvers expect signatures, find none. See turning DNSSEC off safely.
Signatures expired. RRSIGs have a validity window and are refreshed automatically. If a zone has not synced for a long time, its signatures can age out.
The parent is signed and the domain is not delegated where you think. A DS at the registry plus a delegation pointing somewhere else produces a mismatch that looks like a signing problem and is a delegation problem.
What to do first
Restore service, then diagnose. Removing the DS record at your registrar makes the domain unvalidated, which resolvers accept — the zone answers again as soon as the parent's TTL allows. It is not a fix, but it stops the outage while you work out what happened.
Re-signing to match the published DS is faster if the same keys are still in place. If the domain moved providers, they are not.
Checking before it breaks
The failure is invisible from a non-validating resolver, so it is worth checking deliberately after any change to signing or delegation:
dig +cd example.com @1.1.1.1 # should match
dig example.com @1.1.1.1 # the one that fails firstIf those two ever disagree, the chain is broken and most of the internet cannot reach you.
Related
Last reviewed 2026-09-16.
Open a ticket from the control panel, or use the contact form if you cannot sign in. If a domain is down, the status page is the fastest way to find out whether it is us.