Troubleshooting: 'It Must Be DNS'

Telling a DNS failure from something DNS is merely downstream of

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Distinguish NXDOMAIN, SERVFAIL and a timeout, and what each rules out
▸Recognise a failure that is blamed on DNS but happens below it
▸Say what a capture must contain before DNS can be the culprit

Before this lesson — it builds directly on:

'It's always DNS' is a running joke among engineers, and it is half true in a specific way. Almost every connection starts with a name lookup. So *anything* that stops packets leaving a machine also stops names resolving — and the user notices the name failure, because that is the error message they see. DNS is the messenger. Quite often it is also the culprit. Telling the two apart takes one look at the capture.

✗ Common misunderstanding: If names do not resolve, DNS is broken.

Why that's wrong: Almost every connection begins with a lookup, so anything that stops packets leaving the machine also stops resolution. The user notices the symptom, not the cause.

Correct model: Check whether a query on port 53 actually left the machine. If none did, the failure is below DNS and no DNS server is involved.

The packets prove it: The wrong-resolver trace contains ARP requests and nothing else — not one DNS packet, though the user's complaint was that DNS was down.

✗ Common misunderstanding: NXDOMAIN and a timeout mean roughly the same thing — the lookup did not work.

Why that's wrong: NXDOMAIN is a successful lookup with a definitive negative answer: this name does not exist. A timeout means nobody answered, which says nothing about the name.

Correct model: NXDOMAIN means stop and check the spelling. SERVFAIL means try a different resolver. Silence means check reachability.

The packets prove it: Compare the NXDOMAIN and timeout scenarios: one completes in a few milliseconds with a response, the other retries and gives up.

Watch these fields in the lab: dns.flags

Blaming the phone book when the phone line is dead

looking up the number: → the DNS query
the line being dead: → a failure below DNS
checking for a dial tone first: → checking whether a query left at all

Where it breaks down: A dead phone line is obvious to the person holding the handset. A machine with an unreachable resolver reports "could not resolve" — the error message names DNS regardless of where the failure was, which is exactly why the reflex exists.

1No packet on port 53 at all. The resolver's address is wrong or unreachable, so nothing was transmitted. The fault is on this machine or this segment — and no DNS server is involved.
2Query sent, nothing back. The resolver is unreachable or not running. Check the path and the service.
3SERVFAIL. The resolver tried and could not get an answer. Its upstream, or the zone, has a problem. Confirm by asking a different resolver.
4NXDOMAIN. The name genuinely does not exist. DNS worked perfectly; check the spelling. There is nothing to fix in the network.

Watch these fields in the lab: dns.flags

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

A user reports 'DNS is down'. What is the first thing to establish?

What is the practical difference between NXDOMAIN and SERVFAIL?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.