Diagnose four DNS faults from their symptoms

applied · 50 min · Objective 3.4

Task

Inject four different DNS failures into your lab one at a time, observe the symptom each produces, and build the symptom-to-cause table that makes DNS troubleshooting fast. "It's always DNS" is a joke because the symptoms rarely look like DNS.

Steps

  1. Fault one: the resolver is unreachable. Stop bind on Host B. From Host A, try to resolve a name and then to reach the same host by IP address. Note that the address works and the name does not — that asymmetry is the single most useful DNS diagnostic there is.
  2. Fault two: the record is wrong. Restart bind, then change hostb's A record to 192.168.20.99, increment the serial and reload. Resolve, then ping. The name resolves happily and the connection fails, which is why "DNS is working" is never the same claim as "the name is right".
  3. Fault three: a stale cache. Set the zone TTL to 3600, resolve the name, then correct the record and reload. Resolve again from Host A and note it still returns the old answer until the TTL expires — or until you flush.
  4. Fault four: the wrong resolver. Point Host A's /etc/resolv.conf at an address with nothing listening. Observe the timeout behaviour, and note how long applications hang before failing. That delay is why a bad secondary resolver makes everything feel slow rather than broken.
  5. Build the table: symptom, first command to run, likely cause. Four rows.

Verify

dig @192.168.20.10 hostb.lab.internal +short; echo "resolver exit $?"
ping -c 1 -W 1 192.168.20.10; echo "by address exit $?"
dig hostb.lab.internal +noall +answer +ttlid | head -2
dig hostb.lab.internal +noall +stats | grep -E "Query time|SERVER"

The decisive pair is the first two: if the address works and the name does not, the fault is resolution, not connectivity. The TTL in the answer counts down between queries, and watching it reach zero is what proves a stale answer was cached rather than served fresh.

Notes

The table you built is the deliverable, and the four rows are worth memorising:

Name fails, IP works — resolution. Check the resolver, then the record. Name resolves, connection fails — the record is wrong, or the service is down. DNS did its job. Old answer after a change — cache. Check the TTL, and remember you cannot flush someone else's resolver. Everything slow but working — a failing first resolver with a working second. Each lookup waits for a timeout before falling back.

That last one is the cruellest, because nothing is broken. Users report the application, the application team blames the network, and the fix is one line in a DHCP scope. Checking dig +stats query time against each configured resolver individually is how you find it in a minute.