Support Library

DNSSEC Failures (Broken vs Missing)

Unsigned zones still resolve; broken DNSSEC makes validating resolvers return SERVFAIL. How to tell the states apart and fix a broken chain.

Author
CategoryDNS Security
Length3 minute read
UpdatedOctober 24, 2026

The short answer

Missing DNSSEC and broken DNSSEC are very different. A zone without DNSSEC is simply unsigned: resolvers treat it as insecure and answer normally, so it works, just without protection against forged answers. A zone with broken DNSSEC has a chain of trust that does not verify, and every validating resolver answers SERVFAIL. For users behind those resolvers, including 1.1.1.1, 8.8.8.8, 9.9.9.9 and many ISPs, the domain is down.

StateDS in parentZone signedResult at a validating resolver
Unsigned (missing)NoNoInsecure: normal answers, no AD flag
Signed but not anchoredNoYesInsecure: normal answers, no AD flag; the signatures are ignored
SecureYes, matching a keyYes, valid signaturesSecure: answers with the AD flag
Bogus (broken)YesKeys do not match, signatures expired, or zone unsignedSERVFAIL

What breaks a chain

  • Moving DNS providers without removing or replacing the DS record. The new provider signs with different keys, or does not sign at all, and the old DS no longer matches. This is the most common cause.
  • A key rollover where the DS was changed too early, or the old key was removed before caches had the new one. See DNSSEC key rollovers.
  • Expired signatures because the signer stopped running or a hidden primary stopped sending updates.
  • Turning off signing at the provider while the DS stays at the registrar.
  • Name servers that strip RRSIG records or fail to return DNSKEY over TCP.

An algorithm the resolver does not support is different: RFC 4035 tells the resolver to treat the zone as unsigned, so the domain still resolves, just without validation. It does not need the DS removed; move to a widely supported algorithm such as 13 (ECDSA P-256) when you can.

Telling them apart

CommandWhat it shows
dig +dnssec example.com DSInspect the full status and DNSSEC denial of DS, not just an empty answer. Authenticated DS absence makes the child insecure only when the ancestor chain validates and no separate trust anchor applies.
dig +dnssec +norecurse @ns1.example.net example.com DNSKEYThe keys and their signature from your own server
dig @1.1.1.1 example.com ASERVFAIL here, often with an Extended DNS Error such as "DNSKEY missing" or "Signature expired"
dig @1.1.1.1 +cd example.com AAn answer here, with checking disabled, is strong evidence of a validation problem; confirm with EDE, DNSViz or a local validator

DNSViz draws the whole chain and marks the link that fails. Debugging DNSSEC validation errors goes through each error.

Fixing a broken chain

First repair signing or restore the key matching the parent DS: re-sign expired data, publish missing keys or repair synchronization as appropriate. This can recover service sooner while preserving authentication. If repair cannot be completed promptly, removing DS at the registrar is an emergency fallback that deliberately removes DNSSEC protection after cached DS records expire; it is not immediate recovery. Before adding a new DS, verify the signed zone and DNSKEY, then follow the rollover and cache timing. If the provider supports CDS/CDNSKEY and your registry or registrar reads them, it can automate DS updates.

How DNS Panopticon helps

The shared scan looks up DS and DNSKEY at the apex and checks the resolver’s AD flag. Domain Visualizer shows the records; Security Posture shows these findings:

  • DNSSEC is not enabled when there is neither, which is informational but the active scoring model still deducts points for it;
  • DNSSEC broken when there is a DS but no DNSKEY could be retrieved, which is what a validating resolver also returns for many bogus zones;
  • DNSSEC validation not confirmed when both exist but the resolver did not set AD;
  • DNSKEY without a DS when the zone is signed but not anchored, so it is treated as unsigned;
  • DNSSEC is enabled and validates when both exist and AD is set.

It does not walk the chain link by link, so use DNSViz to find the exact fault.

Sources and further reading