WIUNIX ACADEMY
DNSSEC SERVFAIL: locate the broken trust link without disabling validation
Compare validation and checking-disabled queries, inspect parent DS and authoritative DNSKEY/RRSIG, then distinguish cryptographic failures from transport.
Make this guide yoursYOUR 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
THE OUTCOME
What will you have at the end?
Compare validation and checking-disabled queries, inspect parent DS and authoritative DNSKEY/RRSIG, then distinguish cryptographic failures from transport.
Supported operating systems and versions
Primary-documentation review; no production execution or universal installation test is claimed. Examples assume existing tools on Linux and must be adapted to authorized deployment context.
Before you begin
- Authorized operator access, existing tools named in the panels, and a private place to retain diagnostic evidence.
- Use a staging environment or an approved read-only production investigation; review disruptive changes separately.
SERVFAIL does not uniquely mean DNSSEC
A resolver can fail because of unreachable authoritative servers, broken delegation, transport problems or DNSSEC validation. The AD bit is meaningful only when you trust the resolver and its response channel. Requesting DNSSEC records with the DO bit does not itself validate them. This guide investigates an existing signed zone you administer; it does not change registrar DS records or disable validation on a shared resolver.
LET’S BUILD
Check the selected distribution and required tools first
Run on the authorized diagnostic host or disposable lab VM. Compare the installed OS and required packages below with the selected path. Obtain missing tools from the distribution’s enabled official repositories through your approved package-management process; this workflow does not reinstall an existing server or switch its repository.
Ubuntu 26.10 is the reviewed default, with 26.04 LTS and 24.04 LTS alternatives. Check the actual package build and local configuration rather than assuming identical versions.
This host needs client tools only: bind9-dnsutils on Debian/Ubuntu and bind-utils on RPM. Confirm that both dig and delv are available. Do not start named/bind9 or open inbound53 in firewalld/UFW. Authorized DNS queries need working UDP and TCP egress and return traffic; resolve egress policy with the network owner.
Authorized terminal on the host identified in this section
cat /etc/os-release
dpkg-query -W bind9-dnsutils
command -v dig delvRequired packages and tools are identified; resolve missing tools before continuing.
LET’S BUILD
Record the resolver and a known failing name
Run on an authorized Linux diagnostics workstation with BIND dig and delv installed. Query the explicit validating resolver 127.0.0.1, not whichever resolver a different application happens to use. Record time because signature validity and cached failures are time-dependent. The sample authoritative addresses are documentation space; replace them with the current servers for your actual zone and its parent.
Authorized Linux terminal
date -u +'%Y-%m-%dT%H:%M:%SZ'
dig -v
delv -v
dig @127.0.0.1 'www.example.com' A +dnssec +time=3 +tries=1The exact resolver, query, status, flags and any Extended DNS Error text are captured with a UTC time.
LET’S BUILD
Compare a checking-disabled query as a diagnostic only
Repeat the same query with CD. If normal validation returns SERVFAIL and CD yields the expected data, validation is the leading branch. This deliberately asks for possibly unvalidated data and must never become the application’s normal resolution policy. A CD success is not proof that the answer is authentic, and a failure in both modes does not rule out a transport or delegation issue.
Authorized Linux terminal
dig @127.0.0.1 'www.example.com' A +dnssec +cdflag +time=3 +tries=1A clear normal/CD comparison narrows the branch; no permanent resolver setting or application DNS policy changes.
LET’S BUILD
Validate independently with delv
Delv validates using its local trust-anchor context rather than merely trusting an AD flag from upstream. CD on this diagnostic allows retrieval of records that the recursive server may otherwise refuse, while delv still performs its own validation. Retain the validation trace locally; inspect the first failing trust link rather than treating the last SERVFAIL as a root cause. An out-of-date local anchor or clock can invalidate this comparison.
Authorized Linux terminal
delv @127.0.0.1 'www.example.com' A +cdflag +vtraceThe trace either validates the chain or names a specific missing/mismatched key, signature or trust-anchor problem.
LET’S BUILD
Read the delegation before comparing keys
Trace the actual name and inspect where delegation changes. Trace output is discovery data, not an authenticated verdict. Confirm the authoritative server selected for example.com and separately the server authoritative for its parent. A CNAME can move the failure into another zone, so follow that chain explicitly rather than assuming every error belongs to the starting zone.
Authorized Linux terminal
dig 'www.example.com' A +trace +dnssecThe current delegation and any CNAME boundary are known; the configured parent/auth server fields are checked against that evidence.