Troubleshooting

Locate the failing layer before changing configuration

The fastest path to a fix is to ask progressively narrower questions: client, recursive resolver, delegation, authority, record data, validation and transport.

Decision path

From symptom to layer

Name lookup fails

↓

Does a known resolver answer?

Check routing, firewall, port 53/853/443, local stub configuration

Yes

Compare with the intended resolver and inspect cache or policy

↓

Can each authoritative server answer directly?

Check delegation, glue, daemon binding, ACLs, UDP/TCP and IPv4/IPv6

Yes

Check data consistency, DNSSEC validation and stale caches

Symptom matrix

Common patterns

Works by IP, fails by name

Likely stub, resolver, search-domain or DNS policy issue. Confirm the exact queried FQDN.

Works on one resolver only

Compare cached TTLs, DNSSEC validation, ECS/policy behaviour and whether the resolvers see different authority paths.

Works over TCP, fails over UDP

Suspect firewall rules, fragmentation, path MTU or an EDNS size issue.

Works over UDP, fails over TCP

TCP/53 may be blocked. This breaks large answers, zone transfers and standards-compliant fallback.

Unsigned queries work; signed fail

Inspect DS/DNSKEY mismatch, expired RRSIGs, unsupported algorithms or an incorrect validator clock.

Intermittent answers

Query each authoritative server and address independently. One stale secondary or broken IPv6 path can create randomness.

Old answer persists

Read the remaining TTL from the resolver that returns it. Flush only for diagnosis; the public Internet will retain its own caches.

NXDOMAIN unexpectedly

Check whether the name is truly absent, a search suffix changed the query, or a filtering resolver synthesised the response.

Layer-by-layer probes

Use direct queries to remove ambiguity

Question	Command	Interpretation
What does my configured resolver return?	`dig www.example.com`	Shows the client-visible result, flags and remaining TTL.
Does a neutral public resolver agree?	`dig @192.0.2.53 www.example.com`	Use an actual resolver address in practice; compare status, answer and AD flag.
Where does delegation break?	`dig +trace www.example.com`	Follows referrals without depending on one recursive cache.
Does this server answer authoritatively?	`dig @ns1.example.net www.example.com +norecurse`	Look for AA and the intended RRset.
Is the answer too large for the path?	`dig example.com DNSKEY +dnssec +bufsize=1232`	Exercises EDNS and a larger signed response.
Does TCP work?	`dig example.com DNSKEY +dnssec +tcp`	Separates UDP path problems from authority or data problems.
Why did validation fail?	`delv +rtrace www.example.com`	Displays validation steps when supported by the installed tool.

Packet capture

Capture only after forming a hypothesis

A targeted capture can show whether queries leave the host, which source address is selected, whether replies return, whether TCP fallback occurs and whether an ICMP error explains a timeout.

tcpdump -ni any '(udp port 53 or tcp port 53)'

For encrypted DNS, packet capture confirms connection establishment and traffic flow but not the DNS payload. Use endpoint logs or a client tool that exposes TLS and HTTP errors.

Check source-address selection.

On multi-address or multi-homed hosts, replies may leave through a different interface or source address than expected. Use ip route get <destination> from <source> to inspect the kernel’s decision.

Do not “fix” the evidence away

Common troubleshooting traps

Disabling DNSSEC immediately

This may hide the symptom while leaving broken signatures or an incorrect DS in production.

Flushing every cache first

You lose the TTL and provenance information that could explain the stale result.

Testing only the preferred address family

A broken AAAA path can affect some clients while IPv4-only tests remain green.

Using only ping

ICMP reachability does not prove that UDP/TCP port 53 or encrypted DNS listeners work.

Querying only through the usual resolver

A warm cache can conceal a dead or stale authoritative server.