WIUNIX ACADEMY
DNSSEC SERVFAIL: locate the broken trust link without disabling validation
Page 2 of 3. Review the earlier steps and prerequisites before continuing.
YOUR SYSTEM. YOUR STEPS.
Where are you working?
Choose your OS and version. The prerequisites, commands and troubleshooting follow your environment.
USE YOUR OWN VALUES
Configure this tutorial
Set the example values for your environment; related explanations and copy panels update together. Never enter passwords, private keys or tokens. Values stay in this tab and are not sent to the server or share links. Check actual DNS, certificates and network policy before running commands.
Different IP addresses, domains or ports? Open the settings below, change the values and select “Apply to tutorial”, then copy the updated commands.
Set values for my environment5 editable values
LET’S BUILD
Ask the parent for the child’s DS
Query the parent’s authoritative server directly with recursion disabled. A DS belongs at the parent, not in the child as a substitute. Record key tag, algorithm, digest type and digest, plus TTL. Absence of DS can mean an intentionally insecure delegation rather than a broken signed chain; distinguish the expected policy before calling it an outage.
Authorized Linux terminal
dig @203.0.113.54 'example.com' DS +dnssec +norecurse +time=3 +tries=1The response is authoritative for the parent and the actual DS set/absence is recorded without changing registrar data.
LET’S BUILD
Inspect the child DNSKEY and current signatures
Query the zone’s authoritative server directly for DNSKEY and SOA/RRSIG. Confirm the authoritative flag and compare every current authoritative instance if they disagree. A matching key tag is a useful index, not cryptographic proof; the DS digest and signature chain must actually validate. Do not publish a new DS from a random key file just because its tag looks similar.
Authorized Linux terminal
dig @203.0.113.53 'example.com' DNSKEY +dnssec +norecurse +time=3 +tries=1
dig @203.0.113.53 'example.com' SOA +dnssec +norecurse +time=3 +tries=1
dig @203.0.113.53 'www.example.com' A +dnssec +norecurse +time=3 +tries=1Current DNSKEY, RRSIG timing and authoritative consistency can be compared with the parent DS and delv trace.
LET’S BUILD
Separate large-response transport from a bad signature
If UDP fails or truncates, repeat the authoritative DNSKEY request over TCP. DNSSEC responses can be larger; broken TCP53 reachability or path-MTU/fragmentation handling can look like a validation outage. A TCP success does not prove the signature valid. Conversely, a consistent cryptographic validation error is not fixed by increasing UDP buffer size blindly.
Authorized Linux terminal
dig @203.0.113.53 'example.com' DNSKEY +dnssec +norecurse +tcp +time=3 +tries=1UDP/TCP behavior is distinguished from signature validation and assigned to the correct network or DNS owner.
Map the first failed link to its owner
A stale parent DS after a key rollover needs coordinated registrar/parent repair; an expired or not-yet-valid RRSIG needs signer clock/refresh repair; a missing DNSKEY or inconsistent authoritative node needs authoritative publishing repair. If many unrelated zones fail on one resolver, inspect its own clock and managed trust anchors. Do not disable validation globally or delete the parent DS as an incident shortcut.
A safe rollover respects both publication and cache lifetimes
Record the before-state DS/DNSKEY/RRSIG sets and TTLs, then use the DNS provider/signer’s supported rollover procedure. Publish/propagate the required new material before changing the parent dependency, retain overlapping valid keys/signatures for the documented interval and verify every authoritative node. Recovery is a coordinated return to a still-valid trust chain; reverting only one side can preserve the outage. There is no universal sleep duration that safely replaces the actual TTL and signer policy.
LET’S BUILD
Distinguish a fixed chain from retained resolver state
After the authoritative/parent repair, compare normal validated queries from the same resolver and a second approved validating vantage point. TTLs and cached failures may delay convergence. On a BIND resolver you administer, a narrowly scoped cache operation can be appropriate under its runbook, but this guide does not flush a shared cache or restart a resolver. Such actions neither repair bad authoritative data nor establish validation by themselves.
Authorized Linux terminal
dig @127.0.0.1 'www.example.com' A +dnssec +time=3 +tries=1
delv @127.0.0.1 'www.example.com' A +vtraceNormal resolution and independent validation succeed without relying on CD; any remaining cached failure is recorded explicitly.