Diagnose DNSSEC bogus after a change

Bogus is a DNSSEC validation state: a validator expected authenticated data but could not build a valid chain or validate the relevant RRset or denial proof. It is not a synonym for unsigned, unreachable, or merely different DNS data. A validating resolver commonly surfaces the failure as SERVFAIL.

Scope the symptom

Capture:

• exact name, type, response code, flags, and Extended DNS Error;
• named validating resolver and observation time;
• parent DS RRset and TTL;
• child DNSKEY RRset from every intended authority;
• relevant RRSIG inception, expiration, signer, algorithm, and key tag;
• NSEC or NSEC3 proof for negative answers;
• authoritative NS and SOA consistency;
• recent nameserver, registrar, DS, key, signing, or clock changes; and
• intended secure or insecure state.

The registrar or registry path controls parent DS publication. The child DNS operator controls DNSKEY, signatures, denial proofs, and signing time. The recursive-resolver operator controls validation policy and reported result.

Read-only checks

1. Use the DNS Lookup pathway to capture DS, DNSKEY, and the failing RRset from named resolvers.
2. Review the Domain Registration Lookup pathway only to identify the registration and delegation control path; query DNS directly for DS evidence.
3. Query every intended authority directly for DNSKEY and the failing positive or negative answer, including RRSIG and denial records.
4. Compare DS digest, key tag, algorithm, and digest type with the active child key material.
5. Compare signature inception and expiration with reliable current time.
6. Compare validating and non-validating resolver behavior, preserving any EDE code and text.

DNSSEC validation follows the chain from a trust anchor through parent DS and child key material [3]. RFC 8914 defines EDE codes for states such as DNSSEC Bogus, signature expiry, DNSKEY missing, and RRSIG missing [5]. The DNSSEC model distinguishes secure, insecure, bogus, and indeterminate validation states [1].

Interpret the observations

Observation	Supported interpretation	Responsible owner
Parent DS does not match any active child DNSKEY	The delegation chain is mismatched	Parent DS and child signing owners
Matching DS and DNSKEY exist; RRSIG is expired	Signature lifecycle or signing service failed	Child DNS operator
One authority lacks the current DNSKEY or signatures	Signed-zone publication is inconsistent	Child DNS provider
Positive data validates; negative answers fail	NSEC or NSEC3 denial proof is implicated	Child DNS operator
One validator alone reports bogus	Resolver state, clock, policy, or path needs comparison	Resolver operator
No DS exists and the delegation proves insecure	The zone is insecure, not automatically bogus	Intended-state owner

DNSSEC record formats, key tags, signatures, and denial records are defined by RFC 4034 [2].

Likely causes

• stale parent DS after changing providers or keys;
• new DS published before matching child keys are consistently available;
• old keys or signatures removed before cached DS or DNSKEY data expired;
• expired or not-yet-valid RRSIGs;
• signer failure or inconsistent signed zone versions;
• unsupported algorithm or digest type at a validator;
• missing DNSKEY, RRSIG, NSEC, or NSEC3 data;
• clock error at the signer or validator;
• an opt-out or delegation proof problem; or
• resolver-specific cached failure or policy.

Safe next actions

Stop if the prior DS and DNSKEY values, current zone export, intended security state, TTLs, or rollback owner are unknown. Do not make simultaneous parent and child changes without an ordered recovery plan.

• Read-only: preserve chain data and validator evidence before cache refresh or operator intervention changes it.
• Reversible: restore consistent signing or a still-valid prior key at every child authority when the DNS operator’s reviewed state supports it.
• Availability-impacting: replace or remove parent DS only through a reviewed recovery sequence that accounts for DS and DNSKEY cache lifetimes.
• Availability-impacting: for a provider migration, coordinate a supported multi-signer transition or an explicitly planned insecure interval.

RFC 6781 describes operational timing and rollover concerns; DNSSEC recovery is not an instant toggle [4].

Verification

Verify:

1. every child authority serves the same DNSKEY and signed zone state;
2. parent DS matches intended child key material or the delegation is intentionally and provably insecure;
3. signatures are currently valid for positive and negative responses;
4. named validating resolvers report the intended secure or insecure state;
5. no resolver-specific EDE remains unexplained; and
6. the original web, email, or other application path succeeds.

Record the chain and validator result after each ordered recovery step.

What this evidence does not prove

A SERVFAIL, AD-bit difference, or “DNSSEC enabled” control-panel label does not by itself prove:

• the zone is bogus;
• which link in the chain failed;
• every validator behaves the same;
• disabling validation is a safe workaround;
• removing DS is immediately visible to cached resolvers; or
• DNSSEC encrypts queries or authenticates the website itself.

Next protocol layer

If SERVFAIL remains after the chain validates, continue with the broader SERVFAIL diagnosis. If authorities or delegation differ, inspect parent, child NS, and glue. Once DNSSEC is healthy, return to the original web, email, or application symptom.