dotvitals

The registry's DS record does not match any key in the zone

CriticalConfirmeddns.dnssec.ds-mismatch

What this check looks for

The fingerprint your registrar publishes does not match any signing key your zone actually holds. Once resolvers pick this up, they will refuse to resolve your domain.

Why it matters

This is a broken chain of trust waiting for a cache to expire. Some resolvers may still be answering from a copy taken before the mismatch appeared; as those expire, the domain goes dark for every validating resolver, one after another, over the following hours.

When the check passes, your report says: “The registry's DS record matches a key the zone holds”.

What it costs your score

When this check fails it removes 45 points from your DNSSEC score, before the status, confidence and repeat multipliers are applied. DNSSEC carries a weight of 4 in the overall score.

It shares the dnssec.chain family ceiling of 50 points: however many findings that family produces, together they cannot remove more than that from DNSSEC. One underlying problem showing up in several places is still one problem.

Severity
critical
Default confidence
confirmed
Status when triggered
fail
Deduction
45 points
Family cap
dnssec.chain · 50
Category
DNSSEC
Module
Dns dnssec
Fix owned by
registrar
In the ruleset since
2026.09

How the whole score is calculated

How to fix it

Replace the DS record at your registrar with one computed from a key the zone currently publishes.

A DS that points at a key you no longer have takes the domain offline for validating resolvers.

  1. Take the DS record the fix builder computed from your live DNSKEY set.

  2. Replace the stale DS at your registrar with it. If your registrar supports several DS records, add the new one first, wait for the registry to publish it, and only then remove the old — that avoids any window with no valid DS at all.

  3. Wait out the parent's DS TTL before concluding the problem has cleared; resolvers cache the old DS.

  4. If the domain is already unresolvable and you need it back immediately, delete every DS record: the domain becomes unsigned and resolves again within the DS TTL.

How to confirm it worked

  • dig +short DS ‹domain› — compare the key tag against dig +short DNSKEY ‹domain›

  • 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

‹detail›. Each DS record was verified by recomputing the digest from the zone's own DNSKEY set — digest = H(owner name | DNSKEY RDATA), RFC 4034 §5.1.4 — and comparing it with what the registry publishes. This is a real hash comparison over the live records, not an inference. The usual cause is a key-signing key rolled at the DNS host without submitting the new DS to the registrar; key tag ‹key tag› is the one that no longer matches.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the dns dnssec checkerBuild the fix

Other dns dnssec checks