<aside> 🧭
Module 01 · Names, Resolvers & Your First Query
This module assumes zero DNS knowledge. It takes you from "what is a name" to reading a dig response line by line and telling four different kinds of failure apart — which is most of what DNS troubleshooting actually is.
🧠 concept → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (answers hidden)
Prerequisite: none. A Linux shell and an internet connection.
</aside>
<aside> 📇
The analogy. Think of the contacts app on your phone. You never memorise phone numbers — you save a name and tap it. Now imagine nobody had a shared contacts app, and instead everyone kept a paper address book they copied by hand. The moment one person changes their number, every book in the country is wrong, and nobody knows it.
That paper book is /etc/hosts. DNS is the shared, always-current contacts app that replaced it.
</aside>
<aside> 📖
Official docs: RFC 1034 — Domain Names: Concepts and Facilities · RFC 9499 — DNS Terminology (BCP 219) · hosts(5)
</aside>
A network moves packets between IP addresses. Nothing in the network layer understands the word example.com — a router has never heard of it. So something has to turn the name a human types into the address a packet needs. That something is DNS.
The first solution was not DNS. It was one text file, HOSTS.TXT, maintained by hand at the Stanford Research Institute, which every machine on the ARPANET downloaded periodically. Your /etc/hosts file is the direct descendant of it, and it still works exactly the same way.
That design died of three separate diseases, and each one explains a feature of DNS:
| Problem with one file | What went wrong | What DNS does instead |
|---|---|---|
| Load | Every host on the network fetching the same file from one machine | Distributed — the data lives on thousands of independent servers |
| Name collisions | One flat list, so two organisations could not both have a machine called mail |
Hierarchical — mail.a.com and mail.b.com are different names |
| Staleness | Your copy was wrong from the moment someone else changed theirs | Delegated + cached with a TTL — the owner changes it, caches expire on a timer |
<aside> 🔑
The one-line definition worth memorising: DNS is a distributed, hierarchical, delegated, cached database, whose most common use is mapping names to IP addresses. Every word in that sentence is a separate interview answer, and the rest of this module unpacks them in order.
</aside>
<aside> ⚠️
DNS is a database, not a routing protocol. It hands you data and then gets out of the way. It does not connect you to anything, it does not check that the address it gave you is alive, and it has no idea whether the server behind that address is healthy. "DNS is broken" is a diagnosis people reach for far too early — very often DNS answered correctly and quickly, and the thing at the other end was down.
</aside>
🧪 Exercise A1.1 — Look at the file DNS replaced
cat /etc/hosts