DS MISMATCH critical
DS record mismatch (broken chain of trust)
The DS record at the registrar doesn't match the zone's active key, so validators reject every name in the domain with SERVFAIL.
What you see
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27044 ; DS at parent does not match any DNSKEY (broken chain of trust)
What’s actually happening
This is the nastier cousin of a plain DNSSEC failure: a mismatched DS poisons the entire domain — web, mail, every subdomain — for anyone using a validating resolver. Non-validating resolvers still work, so it looks intermittent and 'works for me' depending on the network. dig +cd returns records while a normal query SERVFAILs. The usual trigger is a recent nameserver or DNS-host migration where the old DS was left behind.
Common causes
- Switched DNS providers; new provider signs with its own keys but the registrar still publishes the old DS
- Moved a domain to a host that doesn't support DNSSEC while the DS remained at the registrar
- DS digest type or key tag at the registrar is stale after a key rollover
- Manually entered DS values at the registrar with a typo or wrong digest algorithm
- Registrar and DNS host are different companies and the DS update step was simply skipped
How to fix it
- Confirm the mismatchdig DS example.com @parent-server and dig DNSKEY example.com. The DS digest and key tag must correspond to a key in the live DNSKEY set. dnsviz.net draws the broken link in red and names the offending DS.
- If the zone IS correctly signed by the current hostGenerate the correct DS from the live KSK (your DNS host usually shows the exact DS to publish) and replace the stale DS at the registrar. Wait for the parent zone TTL to propagate before retesting.
- If you migrated to a host without DNSSEC (or don't want it)Delete the DS record at the registrar entirely. Once the parent TTL expires, validators stop expecting a signed zone and resolution recovers. This is the fastest way out of a migration-caused outage.
- Re-test from a validating resolverAfter the DS change propagates: dig example.com @1.1.1.1 should return NOERROR with data instead of SERVFAIL. Verify mail too (dig MX) since the break hit every record type.
- Never break the chain during future migrationsOrder matters: remove the DS at the registrar and wait out the TTL BEFORE moving nameservers, then re-add a fresh DS only after the new host is live and signing.
Stop it recurring
Treat the DS at the registrar as part of any nameserver change — remove or update it in the same maintenance window, never after.
Related errors