DNS: The Internet's Phone Book

Before you can call anyone, you need their number — and names are useless to the phone system. So you open a phone book, look up a name, and memorize the numbers you dial most. Now imagine the phone book is shared by billions of people, entries change every few minutes, and the book itself is spread across thousands of offices on different continents. That is the daily reality of naming on the internet — and it works so smoothly that most people never notice it exists. They only notice when it breaks: a website that loads fine for your friend but refuses to load for you, while everything else on your computer works perfectly. Same name, same internet, different answer — and the phone book is the prime suspect.

Here's the puzzle.

Scenario. Two laptops sit on the same office Wi-Fi. Laptop W loads the company portal fine; Laptop B gets "can't reach this site" — while everything else on Laptop B works. IT swears the portal server is healthy. Both owners ran the same lookup command. Your job: say which side is broken — Laptop B's helper or the name's owner — prove it with one output line, and give the one config line that fixes it.

Given artifacts. The office (hover any device for details):

Laptop W (working) — dig portal.example.com
  ; <<>> DiG 9.18.1 <<>> portal.example.com
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48291
  ;; QUESTION SECTION:
  ;portal.example.com.		IN	A
  ;; ANSWER SECTION:
  portal.example.com.	5	IN	A	10.0.5.20
  ;; Query time: 4 msec
  ;; SERVER: 192.168.1.1#53

Laptop B (broken) — dig portal.example.com
  ; <<>> DiG 9.18.1 <<>> portal.example.com
  ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51733
  ;; QUESTION SECTION:
  ;portal.example.com.		IN	A
  ;; Query time: 2003 msec
  ;; SERVER: 192.168.1.9#53

Your task: Deliver three things: (1) which side is broken — Laptop B's helper (its configured resolver) or the name's owner (authoritative side); (2) the exact output line that proves it; (3) the one config line that fixes it.

Workspace: Analyze-and-answer — type your three answers below, then check the commitment box to reveal the worked answer.

☐ I've attempted this challenge and thought it through. (Checking reveals the worked answer in S7 — honor system: the page hides it until you commit.)

Names in, numbers out

DNS (the Domain Name System — the internet's phone book: the machinery that turns names you type into numbers the network can use) exists because humans remember names and networks route numbers. Your computer never asks the whole internet directly. It asks one designated helper — the resolver (the phone-book assistant your computer queries first; usually run by your office or internet provider) — and the resolver does the legwork.

At the far end of that legwork sits the authoritative server (the office that owns the records for a name and gives the final, official answer — like the phone company's own listing department). Between your resolver and the authoritative server lies a chain of referrals, and every link in that chain can fail in its own way — which is exactly why "down for me but not you" happens.

Why this matters for the challenge: the two laptops asked two different helpers about the same name — keep "helper" and "owner" as separate suspects.

The walk: helper → root → neighborhood → owner

A resolver that doesn't know the answer walks down a hierarchy, and the walk is always the same shape:

1. Your computer → resolver: "What's the address of portal.example.com?" (This is the only step your computer ever sees.)
2. Resolver → root server: the root server (the top of the phone book — it knows nothing about individual names, only where each neighborhood lives) answers: "Not mine — ask the .com servers."
3. Resolver → TLD servers: the TLD (short for top-level domain — the last chunk of a name, like .com or .org; think "the neighborhood") answers: "Not mine — ask the owner of example.com."
4. Resolver → authoritative server: the owner answers with the actual record.
5. Resolver → your computer: the final answer, delivered in milliseconds.

Each step is a referral, not an answer — "I don't know, but they will." That design is why the system scales to billions of names: no single office holds the whole book.

Why this matters for the challenge: a SERVFAIL means this walk broke down somewhere — the status word tells you the helper gave up, and the working laptop tells you where it didn't break.

Record types: the pages of the phone book

The owner doesn't keep one kind of entry — it keeps several, each answering a different question:

A lookup for a website usually ends at an A (or AAAA) record — sometimes after following one CNAME nickname to get there.

Why this matters for the challenge: both laptops asked for the A record — the main listing — so record type isn't the variable; the helpers are.

TTL and caching: memorizing numbers you dial a lot

No helper walks the full chain for every question — that would take seconds, every time. Instead it memorizes answers, and each answer carries a TTL (short for time to live — how many seconds the helper is allowed to remember the answer before it must ask again). A TTL of 5 means "remember this for 5 seconds"; a TTL of 3600 means "remember it for an hour."

Caching is why the internet feels instant — and why changes take time to spread. When a website moves to a new address, everyone whose helper memorized the old answer keeps going to the old address until their TTL expires. Short TTLs make changes fast but hammer the owners with questions; long TTLs are efficient but sluggish to update.

Why this matters for the challenge: Laptop W's answer came with TTL 5 — an aggressively short memory. Noteworthy, but as you'll see in the worked answer, a red herring: it still delivered a correct answer.

Reading dig and nslookup

dig output is a lab report with four parts that matter:

• status: — the verdict word. NOERROR means "here is your answer" (check the ANSWER SECTION). NXDOMAIN means the owner itself says "no such name exists" — the name is wrong or unregistered. SERVFAIL means the helper failed — it tried the walk and couldn't complete it. That distinction is the whole diagnostic game.
• QUESTION SECTION — what you asked (name + record type). Confirm it matches what you meant to ask.
• ANSWER SECTION — the records found. Absent on failures — its absence is itself evidence.
• SERVER: — which helper answered. When two machines disagree, this line names the differing variable.

nslookup shows the same facts in friendlier prose ("Server:", "Address:", "Name:") — same suspects, different layout.

Why this matters for the challenge: your proof line is one of these four parts — you'll know which the moment you compare the two verdict words.

DNS over HTTPS, in one line

DNS over HTTPS (asking the phone book inside an encrypted web connection, so anyone watching the wire sees only web traffic, not your questions) exists because classic DNS questions travel in the open — readable by anyone between you and the helper. One line, as promised: it's the same phone book, asked through a sealed envelope.

Why this matters for the challenge: it doesn't change the diagnosis — a sealed envelope to a dead helper still gets no answer.

Platform: Cisco IOS / IOS-XE

! PLAIN-ENGLISH: Tell the router which helpers to ask for name lookups (tried top-down, in order).
ip name-server 192.168.1.9
ip name-server 192.168.1.1
!
! PLAIN-ENGLISH: Let the router answer name lookups for the LAN itself (it becomes the office helper).
ip dns server

Sample output of the verification command (shown so you can read it, not configure it):

R-1# show hosts
Default domain is example.com
Name servers are 192.168.1.9, 192.168.1.1

Host                    Port  Flags      Age  Type   Address(es)
portal.example.com      -     -          0    IP     10.0.5.20

⚠️ Remove this, break that: with no ip name-server at all, the router cannot resolve a single name — ping portal.example.com fails with "unknown host" even though the whole network is healthy. ⚠️ Remove this, break that: a dead entry listed first (192.168.1.9 here) makes every lookup stall or fail before the working helper is ever tried — always put the working helper first. ⚠️ Remove this, break that: no ip domain-lookup switches the whole thing off — the router won't even attempt DNS, and every hostname becomes "unknown."

• A lookup walks a chain — your helper, the root, the TLD, the owner — and each broken link returns a different failure word.
• SERVFAIL blames the helper; NXDOMAIN blames the name itself — read the status word before touching anything.
• If one client resolves a name and another doesn't, the name is fine — compare their helpers.
• TTL is a countdown on memorized answers: short TTLs spread changes fast but make helpers ask more often.
• A CNAME is a nickname pointing at a real name; the real address always comes from an A (or AAAA) record at the end of the chain.

Next: Ethernet and Cabling: The Physical Layer — Names now turn into numbers — but numbers still have to travel as electricity and light. Next: the cables themselves, and why a dirty connector can quietly halve your speed.