Skip to content

Lab: DNS Troubleshooting

Pairs with: DNS Resolution and Troubleshooting

Environment: A single disposable VM with internet access and dig installed (apt install dnsutils / dnf install bind-utils).

Starting conditions

  1. A VM with working internet connectivity and DNS resolution, confirmed by dig +short example.com returning an IP address.
  2. Root/sudo access to edit /etc/hosts and, if present, resolvectl.

Instructions

Part 1 — Break it, deliberately

Introduce one of the following faults:

  • Hosts-file shadowing: add a line to /etc/hosts mapping example.com to 127.0.0.1 (a deliberately wrong address).
  • Broken resolver: if the system runs systemd-resolved, set a non-existent DNS server: sudo resolvectl dns eth0 192.0.2.254 (a reserved, non-routable test address). On a system without systemd-resolved, edit /etc/resolv.conf directly to the same bogus address.

Part 2 — Diagnose it

  1. Run dig example.com and dig example.com @8.8.8.8 (an external server, bypassing your local configuration) and compare the two results.
  2. Run getent hosts example.com and compare it against both dig results.
  3. Determine, from these three results alone, whether the fault is in /etc/hosts, the local resolver configuration, or neither.

Expected results

  • Hosts-file fault: dig example.com (which does NOT consult /etc/hosts — dig talks to DNS servers directly) will return the real, correct address. getent hosts example.com (which DOES follow /etc/nsswitch.conf's files, dns order) will return 127.0.0.1 instead. This discrepancy between dig and getent is the diagnostic signal.
  • Broken resolver fault: dig example.com (using the system's default, now-broken resolver) will time out or fail outright. dig example.com @8.8.8.8 (explicitly bypassing it) will succeed. This discrepancy — one works, one doesn't, for the exact same query — isolates the problem to the local resolver configuration specifically, not the domain or the wider internet.

Diagnosis checklist

  • [ ] Did you use dig, not ping, as your primary tool? (ping gives you success/failure but none of the "which server answered, did the query even reach a real server" detail.)
  • [ ] Did you correctly identify whether /etc/hosts was involved, based on the dig vs. getent discrepancy specifically (not a guess)?
  • [ ] Could you explain why dig ignores /etc/hosts while getent hosts (and ordinary application name resolution) does not?

Success criteria

Given either fault (without being told which), you can state — based only on command output, not a guess — whether the problem is /etc/hosts, the resolver configuration, or an actual upstream DNS failure, within two commands.

Cleanup / rollback

# Remove the test entry from /etc/hosts if you added one:
sudo sed -i '/example.com/d' /etc/hosts

# Restore resolver to a working DNS server:
sudo resolvectl dns eth0 1.1.1.1 8.8.8.8     # systemd-resolved
# — or, without systemd-resolved —
echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf

Confirm with dig +short example.com returning the real address again before considering the lab environment restored.