Validating resolvers refuse to resolve the domain
What this check looks for
Public resolvers that check DNSSEC cannot resolve your domain at all. For everyone using one of them — a large share of the internet — your website and email simply do not exist.
Why it matters
This is the most severe DNS failure there is, and it is invisible from a machine using a non-validating resolver. The domain looks perfectly healthy from your desk while Cloudflare, Google and Quad9 users get nothing. It caps the overall score for that reason.
When the check passes, your report says: “Validating resolvers resolve the domain without error”.
What it costs your score
When this check fails it removes 60 points from your DNSSEC score, before the status, confidence and repeat multipliers are applied. DNSSEC carries a weight of 4 in the overall score.
This rule declares no family, so it stands on its own rather than sharing a ceiling with related checks.
- Severity
- critical
- Default confidence
- high
- Status when triggered
- fail
- Deduction
- 60 points
- Family cap
- none
- Category
- DNSSEC
- Module
- Dns dnssec
- Fix owned by
- registrar
- In the ruleset since
- 2026.09
How to fix it
Restore the chain of trust, or remove the DS record so the domain resolves unsigned.
Until it is fixed, everyone using a validating resolver cannot reach the domain at all.
Decide first whether you want the domain signed. If a rollover went wrong and you need service back within minutes, deleting the DS record at your registrar restores resolution for everyone — the domain is then unsigned, which is a downgrade but not an outage.
If you want it signed: compare the DS records at your registrar against the DNSKEY set your DNS host currently publishes, and republish a DS computed from a key that actually exists.
Wait for the registry to publish the change and for the old DS to fall out of resolver caches — up to the parent's DS TTL, often a day.
Confirm with a validating resolver before you consider it done.
How to confirm it worked
dig @1.1.1.1 ‹domain› A — expect an answer rather than SERVFAIL
delv ‹domain› A — expect "fully validated"
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
These validating resolvers returned SERVFAIL for ‹domain› while the zone's own nameservers answered normally: ‹resolver list›. A DS record is published at the registry: ‹ds present›. SERVFAIL is the documented response of a validating resolver when validation fails (RFC 4035 §5.5). The two usual causes are a DS at the registry that no longer matches any key the zone publishes — after a key rollover the registry was not told about — and a zone that has stopped being signed while its DS remains. The resolver does not say which, so check the DS-mismatch finding alongside this one.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.
Other dns dnssec checks
- The zone is signed with a deprecated algorithm
- Signatures were read but not cryptographically verified
- The registry's DS record does not match any key in the zone
- The zone is signed but the registry has no DS record
- A DNSSEC key is shorter than the recommended size
- The zone's record names can be enumerated
- NSEC3 is configured with extra hash iterations
- NSEC3 opt-out weakens proof for unsigned subdomains
- DNSSEC could not be checked
- A DNSSEC signature has expired
- A DNSSEC signature expires within seven days
- The zone publishes keys but no signatures