Week 2 review + DNS Detective

The Week-2 muscle: follow the request from name to response

Section 1 of 5 · ~2 min

Week 1 was about a single box. Week 2 was about what happens between boxes — and today those six days stop being separate topics and become one reflex: when something is “down,” you follow a single request from a typed name all the way to a served response, and you stop at the first layer that fails.

Every request crosses the same four layers, and you now own a tool for each:

Name → IP. A browser can’t connect to shop.example.com — it needs an address. DNS turns the name into an IP (Day 11), and dig (Day 12) shows you exactly what answer came back, and from which resolver.

Reachable? Once you have an IP, is the host even on the network? ping (Day 12) tests that the box answers at all — but only that.

Port open? A host can be up while the service is dead. ss -tlnp (Day 12) lists what is actually listening and on which port, so you know whether anything is home on 443.

Responding? Finally, does the service answer correctly? curl -I (Day 11) makes the real request and reads the status line — 200, 502, or a hang.

Three more days sit underneath all four: Days 8–9 gave you grep, sed, awk and pipes to slice noisy output down to the one line that matters; Day 10’s systemctl and journalctl tell you whether the service is even running and what its logs say; and Day 13’s SSH is how you run every one of these commands on a server that isn’t your laptop.

Real world: Posting a letter needs four things to line up — the right address from the directory, open roads to carry it, a mailbox that accepts it, and someone home to read it. A site that’s “sometimes down” is usually a directory listing two addresses where one house was demolished: half your letters arrive, half bounce, and nothing looks broken if you only check once.

A named example makes the top layer concrete. When engineers suspect DNS, they compare their own resolver’s answer against a known-good public one — Cloudflare’s 1.1.1.1 resolver, launched in 2018 — with dig @1.1.1.1 shop.example.com. If the public resolver returns the right IP and yours returns a stale or empty answer, the fault is your resolver or its cache, not the domain. That one comparison splits “DNS is broken everywhere” from “DNS is broken only for me” in seconds.

That layered walk is why today is a mission, not a lecture. Reading the flow doesn’t build the reflex — chasing a real intermittent outage does. DNS Detective below hands you a site users swear is “sometimes down” and makes you follow the trail, layer by layer, with exactly the week-2 tools, until the story finally makes sense.

Hands-On Lab

Section 2 of 5 · ~2 min

Today the lab is the mission. No WSL2, no setup, nothing to paste — DNS Detective runs entirely in your browser.

This is your Week-2 boss fight. Support is fielding angry tickets: the site is “sometimes down” — it loads for some users, fails for others, and a refresh sometimes fixes it. Nobody can reproduce it reliably, which is exactly why it’s a detective case. Everything you need is something you already learned in days 8–13, so play it as the layered walk from the diagram:

• Name → IP — dig the domain and read the answer section. Intermittent trouble is the tell of more than one answer: look for two A records where one points somewhere dead (days 11–12).
• Reachable? — ping each IP to see whether every host the name resolves to is actually alive on the network (day 12).
• Port open? — use ss/curl to confirm the service is listening and answering on the suspect host, not just that the box is up (days 11–12).
• Read the evidence — grep and pipes trim the noisy output to the line that matters, journalctl shows what the service logged, and it all happens over an ssh session onto the box (days 8–10, 13).

Type help in the terminal to see the supported commands, and hint if you stall — it nudges without solving. There’s no penalty for poking around; the whole point is to run the name → route → port → response walk with your hands until it’s reflex, and to feel why “sometimes” almost always means one member of a set is broken. Close the case — then, if you want the bragging rights, replay it and try to pin the culprit in fewer commands.

When the verdict lands, come back and note below which layer tripped you up — that reflection is where the lesson sticks.

Common Errors & Fixes

Section 3 of 5 · ~3 min

These are the mistakes that trip people up when they run the week-2 troubleshooting walk for real on Ubuntu 24.04 — the same layers the mission rehearses. Read the error text slowly; parsing it is the skill.

Common error: Reaching for netstat (or ifconfig) out of habit to see what’s listening, on a stock noble box that never had them:

Command 'netstat' not found, but can be installed with:
sudo apt install net-tools

Why: The net-tools package (netstat, ifconfig, route) is legacy and is not installed by default on Ubuntu 24.04. The shell searched $PATH, found nothing named netstat, and Ubuntu’s command-not-found helper suggested the old package instead of the modern tool.

Fix: Use the iproute2 tools that are installed: ss -tlnp to list listening sockets (the direct netstat -tlnp replacement) and ip addr / ip route in place of ifconfig / route. Don’t apt install net-tools just to keep an old habit.

How you’d spot it in prod: A health-check or deploy script that calls netstat/ifconfig fails the moment it runs on a fresh minimal host or slim container image. command not found in the job log means the script assumes tooling the base image doesn’t ship — port the script to ss/ip, don’t fatten the image.

Common error: Concluding the service is healthy because ping came back clean:

64 bytes from 203.0.113.10: icmp_seq=1 ttl=56 time=11.3 ms
64 bytes from 203.0.113.10: icmp_seq=2 ttl=56 time=10.9 ms

Why: ping uses ICMP, which only proves the host is powered on and reachable on the network. It says nothing about the application: the app can be crashed, nginx can be listening on the wrong port, or a firewall can allow ICMP while blocking TCP 443. A green ping is the weakest possible “up.”

Fix: Test the actual path the users take. Confirm something is listening with ss -tlnp | grep ':443', then make the real request with curl -I https://host and read the status line. Only a real response proves the service is up.

How you’d spot it in prod: An uptime monitor configured to ping the host stays green while users get connection-refused or 502s. If the dashboard is happy but the tickets aren’t, check whether the monitor tests the port and HTTP response — not just ICMP.

Common error: Reading dig output too fast and declaring “DNS is down” on a plain typo:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42137
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1

;; AUTHORITY SECTION:
example.com.  900  IN  SOA  ns.example.com. hostmaster.example.com. 2026070901 7200 3600 1209600 900

Why: NXDOMAIN means the name genuinely does not exist — almost always a typo or the wrong domain, not a broken resolver. A truly broken resolver returns SERVFAIL or times out; a name that exists but has no record of that type returns NOERROR with an empty answer section. The status line tells you which world you’re in.

Fix: Reread the header status before acting. Check spelling, query the right record type (dig shop.example.com A), and cross-check against a public resolver with dig @1.1.1.1 shop.example.com to see whether the answer differs from your local one.

How you’d spot it in prod: An alert firing “DNS failure” that’s really a misconfigured hostname in a config file or a trailing-dot / search-domain slip. Grep the config for the exact name you queried before you touch anything on the DNS servers.

DNS & Networking Interview Questions

Section 4 of 5 · ~1 min

The “sometimes down” walk-through and the DNS basics below are among the most common Phase-1 networking screening questions — a calm, layered answer beats a clever one every time. The answer bank renders right after this note. Cover each answer, say your own version out loud first, then compare — recalling before revealing is what makes it stick for interview day.

Go Deeper

Section 5 of 5 · ~1 min

Optional extras if you have ~30 more minutes:

• 5 min — Replay DNS Detective and try to pin the culprit in the optimal command count — speed here is just knowing the layered walk cold.
• 10 min — Run dig +short shop.example.com on any real domain (try one with a CDN) and watch the answer sometimes change between runs; then run man dig and skim @server and +trace.
• 15 min — Reread the Networking for DevOps guide end to end now that dig, ss, ping and curl mean something — the second pass is where DNS, ports and routing consolidate into one mental model.