DNS: The Internet's Directory

DNS: The Internet's Directory

What you'll learn

• Explain why name resolution exists, using the book's phone-book analogy — and why a flat phone book cannot scale
• Trace a name through the DNS hierarchy: root → top-level domain → authoritative server
• Distinguish recursive from iterative queries at awareness level, and explain caching and TTL
• Read the everyday record types: A, AAAA, CNAME, MX, TXT, SRV, SOA, NS
• Explain encrypted DNS (DoH/DoT) and why modern captures show fewer DNS packets — then query DNS by hand with nslookup and dig

This lesson builds on three chapters of Dr. Tahseen Al-Doori's Network Essentials: Chapter 4 introduces the DNS server among the network's core devices, Chapter 5 places DNS in the protocol suite and dissects the fully qualified domain name, and Chapter 10 — the book's richest DNS material — explains why the system is shaped like a tree and hands you nslookup. Both of the book's teaching analogies survive to 2026 intact; the encryption story is this lesson's modern layer.

Names for humans, numbers for machines

Start from the book's first analogy, a keeper: DNS is the Internet's phone book. You want to call a person, but the telephone network only understands numbers — so you look the name up and dial the number printed beside it. Likewise, you want example.com, but every packet you learned to build in Module 2 needs a destination IP address in its header. Something must translate, instantly and reliably, every time anyone types a name. That translation is name resolution, and DNS — the Domain Name System — performs it.

The name being resolved has anatomy of its own. A fully qualified domain name (FQDN) — www.example.com — reads right to left in widening circles of authority: com is the top-level domain (TLD); example is the domain registered inside it; www names a particular host (or an alias — a distinction a record type will sharpen shortly). The book teaches this three-part skeleton, and it still fits, with one 2026 stretch: names today often nest deeper (mail.corp.example.com), each dot adding one more circle. Right to left, general to specific — keep that reading direction; the whole system is organized around it.

Why not one big phone book?

Here is the design question the book poses beautifully in Chapter 10. Early name resolution was a flat phone book: a single file listing every machine name and its address, consulted top to bottom. That works for an office. Now scale it to the Internet: hundreds of millions of domains, changing constantly, queried billions of times per second. One alphabetical mega-directory would be impossibly large, impossibly busy, and impossibly stale — imagine one clerk, one ledger, and the whole world in line at the counter.

The book's second analogy shows the escape, and it is the best mental picture of DNS ever offered to beginners: a family tree. You don't find a distant relative by reading every name in the nation's census; you ask upward — your parents know their generation, your grandparents know theirs — and the question travels the tree until it reaches the one branch that keeps track of the person you want. Nobody knows everyone; everyone knows who to ask next. The search visits a handful of people instead of millions of names.

DNS is that family tree, formalized:

• At the top sit the root servers — the ancestors. They know one thing: which servers handle each top-level domain. (Thirteen root server identities exist, each replicated worldwide — Module 4's anycast, working for a living.)
• Below them, each TLD's servers (com, org, net, country codes like uk and sa, and hundreds of newer ones) know which name servers are responsible for every domain registered under them.
• At the bottom, each domain's authoritative servers hold the actual answers — the records for example.com, maintained by whoever runs that domain.

No single machine holds the whole map. Authority is delegated down the tree, each level knowing only its own children — which is precisely why the system scales, survives failures, and lets millions of independent organizations manage their own names without asking anyone's permission.

The resolution journey

So what actually happens in the milliseconds after you press Enter? Two kinds of asking cooperate — this is the recursion-versus-iteration distinction, at the awareness level this course needs.

Your machine itself is lazy, by design. Its built-in stub resolver sends one question to a recursive resolver — typically your ISP's, your router's, or a public one — phrased as: "Get me the address for www.example.com. Do whatever it takes; I'll wait." That is a recursive query: full answer demanded, legwork delegated.

The recursive resolver then does the legwork iteratively — walking the tree one step at a time: it asks a root server, which replies not with the answer but with a referral ("ask the com servers — here they are"); it asks a com server, which refers again ("ask example.com's own name servers — here they are"); it asks the authoritative server, which finally answers with the record. The resolver hands the finished answer back to your machine, which caches it and gets on with building packets.

Caching is what makes this affordable. Every answer carries a TTL (time to live) — a number of seconds the answer may be reused before it must be looked up again. Your machine caches, your resolver caches, and popular names are answered from memory in a fraction of a millisecond, no tree-walk needed. The cost of caching is the flip side: when a domain's records change, old answers linger until TTLs expire — the reason "the DNS change hasn't propagated yet" is a sentence you will hear (and, after this lesson, be able to explain properly: nothing propagates — caches expire).

Reading the records

The authoritative server's answers come as typed resource records — and the types are a vocabulary you will use for the rest of your career. Chapter 10 lists the classic set; here it is completed and labeled for 2026. (One kind correction on the way in: the book's list abbreviates the alias record as "CN" — the registry name, and what every tool prints, is CNAME.)

A detail worth pinning because the lab will show it: a single name routinely holds several records of different types at once — example.com has A records, AAAA records, MX records, TXT records and NS records simultaneously. Which one you receive depends on which type you ask for — and asking for specific types by hand is exactly the skill the lab drills.

From the textbook to 2026: DNS goes dark (in a good way)

Everything above works today precisely as the book taught — hierarchy, delegation, records, caching are the stable core. What changed is privacy. Classic DNS queries travel in cleartext on port 53, which means everyone between you and your resolver — the coffee-shop Wi-Fi, the hotel network, the ISP — can read (and log, and sell, and sometimes rewrite) every name you look up. Your browsing content moved to HTTPS years ago; your browsing intentions still leaked through DNS.

Two encrypted transports closed the leak:

• DoT — DNS over TLS (port 853, current): the same DNS conversation wrapped in TLS on its own dedicated port. Clean, visible-as-encrypted-DNS, favored in operating systems and on Android.
• DoH — DNS over HTTPS (port 443, current): DNS queries dressed as ordinary HTTPS traffic — last lesson's "universal door" pattern applied to name lookups. Favored by browsers, which increasingly enable it by default.

The practical consequence you will meet in minutes: a modern machine's captures may show few or no port-53 packets, because the browser is quietly resolving names over DoH inside its HTTPS streams. When your Wireshark window shows less DNS than this lesson led you to expect, that is not failure — that is 2026. (The command-line tools in the lab still speak classic port-53 DNS by default, which is exactly why the lab can still show you the protocol in the open.)

Watch: How DNS Works — Computerphile

Why this video earns its place. Computerphile is the University of Nottingham's long-running computer-science channel, and Dr Mike Pound is among its clearest explainers. In about eight minutes of characteristic marker-on-paper drawing, he walks the exact journey you just read — how a name you type becomes an address a packet can use — with the resolver's tree-walk drawn out step by step. Watching the hierarchy sketched consolidates the family-tree picture like nothing else at this length.

As you watch, notice:

• The core question — how the names people type get matched to the addresses machines need — framed exactly as our phone-book section framed it.
• The chain of servers consulted in turn: root, then TLD, then the domain's own — our resolution journey, drawn live.
• Who does the walking: the resolver performs the step-by-step legwork while your machine waits for one finished answer — the recursive/iterative split in action.
• Answers being remembered along the way — the caching that makes the whole system affordable, and the reason repeat lookups are instant.
• What the video leaves for us: it is conceptual by design — record types (our table) and the encrypted-DNS turn are this lesson's text. In particular, the video predates DoH/DoT becoming browser and OS defaults, so treat our "DNS goes dark" section as the current-practice layer on top of its (still fully correct) mechanics.

The video reinforces visually what you just learned — the lesson is complete without it.

Lab: DNS Scavenger Hunt — nslookup, dig, then Wireshark

Time to query the tree yourself. Two tools, both from the book's own toolkit chapter, both current: nslookup (everywhere — Windows, macOS, Linux) and dig (Linux/macOS native; comes with modern BIND tools on Windows — but nslookup alone completes this lab fine). You will resolve six records of five different types, then watch your queries cross the wire.

Objective. Resolve six specific records by hand, read each answer's parts, and capture live DNS traffic in Wireshark.

Setup. Any computer with a working network. Wireshark installed (Module 2). No changes to your system — queries are read-only. Where outputs are shown below, they are authored examples of the shape to expect: live values (addresses, TTLs, server lists) change over time — that is DNS working, not the lab failing.

Steps — the hunt. Record each find: the record type, the answer, and the TTL where shown.

1. An A record. Run:

   codeCopy

   nslookup example.com
   

   Expect the shape:

   codeCopy

   Server:   your-router-or-resolver
   Address:  192.168.10.1
   
   Non-authoritative answer:
   Name:     example.com
   Address:  96.7.128.175
   

   Two reading notes. The top block names which resolver answered you — your first finding is that your machine asks a middleman, exactly as the resolution journey described. And "non-authoritative answer" is honesty, not error: the server that answered is not one of example.com's own authoritative servers — it recursed on your behalf and is relaying the result. The label describes the answering server's status, not where the bytes came from; what actually reveals a cached copy is the TTL, counting down a little further on every repeat query.

2. An AAAA record — the IPv6 sibling. Ask for the type explicitly:

   codeCopy

   nslookup -type=AAAA example.com
   

   (dig users: dig AAAA example.com — dig prints a fuller report; find the ANSWER SECTION.) Expect one or more addresses in Module 4's colon-hex notation, e.g. 2600:1406:bc00:5300:b81a:a45f:ce2c:36a2 — your values will differ. Same name, second address family: dual stack, visible in the directory.

3. An MX record — who takes the mail:

   codeCopy

   nslookup -type=MX gmail.com
   

   Expect several lines shaped like mail exchanger = 5 gmail-smtp-in.l.google.com — a priority number and a server name per line. Lowest priority number is tried first; the rest are fallbacks. Notice the answers are names, which a mail server must then resolve to addresses — DNS layering on DNS.

4. A TXT record — the free-text workhorse:

   codeCopy

   nslookup -type=TXT example.com
   

   Expect quoted text; among it something shaped like "v=spf1 -all" — that is an SPF mail policy living in a TXT record, declaring which servers may send mail for the domain (this one declares: none). Module 7 returns to SPF; today's point is that TXT records carry real, machine-read policy.

5. An NS record — the delegation made visible:

   codeCopy

   nslookup -type=NS example.com
   

   Expect a short list shaped like nameserver = a.iana-servers.net. These are the authoritative servers from our tree — the branch of the family that keeps example.com's records.

6. A CNAME record — the alias. Query a name that is famously an alias:

   codeCopy

   nslookup www.wikipedia.org
   

   Expect the answer to arrive via another name — output shaped like www.wikipedia.org canonical name = dyna.wikimedia.org, followed by that target's addresses. (The exact target name may differ as operators reorganize — the finding is the CNAME hop itself: you asked for one name and were formally redirected to the canonical one.)

Steps — watch it on the wire.

7. Start a Wireshark capture on your active interface. In the display filter bar, type dns and press Enter.
8. Rerun two or three of the hunt queries in your terminal.
9. Watch paired lines appear: a query (Info column shaped like Standard query 0x1c2a A example.com) and its response moments later (Standard query response ... A 96.7.128.175). Click a query line and expand the Domain Name System band in the details pane: there is the question, the type, and — in responses — the answers and TTLs you have been reading in the terminal, now visible as protocol fields inside a UDP datagram on port 53 (last lesson's table, live).
10. Now browse a website in your browser and watch the filter. If few or no new DNS lines appear for names you clearly just visited — your browser is resolving over DoH inside encrypted HTTPS, exactly as the modernization section predicted. Note which behavior you observed; both are correct 2026 results.
11. Stop the capture. Nothing to save unless you want it.

Expected result. Six recorded finds spanning A, AAAA, MX, TXT, NS and CNAME; a capture showing your command-line queries as cleartext DNS over UDP port 53; and a browser observation that either shows classic DNS or demonstrates its encrypted disappearance.

Verify. For each find you can name the record type queried, read the answer aloud correctly (address, priority + server, quoted policy, server list, or alias hop), and you can point in Wireshark at one query/response pair and locate the TTL inside the response.

Questions.

1. Your step-1 answer said "non-authoritative." Which server would give an authoritative answer for example.com, and which of your six finds told you its name?
2. You run the same nslookup example.com twice in a row. The second answer returns noticeably faster and its TTL is lower. Explain both observations with one mechanism.
3. The MX answers for gmail.com are names, not addresses. What must a sending mail server do next, and which record type will that next step use?
4. In step 10, a colleague's capture shows abundant port-53 DNS while yours shows almost none for the same browsing. Give the likely explanation and the port numbers each machine's lookups are using.

(Answers: 1 — one of the domain's authoritative name servers, and find 5 (the NS record) listed exactly those servers by name. 2 — caching: the first answer was fetched and stored by your resolver (and your machine); the second was served from cache — faster — and TTLs count down while an answer sits in cache, so the remaining lifetime is lower. 3 — resolve the mail exchanger's name to an address before connecting: an A (or AAAA) lookup for the server name. 4 — your browser resolves via DoH (encrypted, inside HTTPS on port 443) while the colleague's setup still uses classic system DNS on port 53 — both normal in 2026.)

If it goes wrong.

• nslookup reports "server can't find" / NXDOMAIN for a hunt name. Check spelling first — DNS is unforgiving of typos. If the spelling is right, the specific record may genuinely have changed (live Internet, authored expectations); the record type exercise works with any domain you substitute.
• Answers differ from the printed examples. Expected — addresses, TTLs, server names and even the CNAME target drift over time. You are grading the shape of the answer, not the digits.
• dig not found on Windows. Use nslookup for everything here (-type= covers all six finds), or install BIND's tools later — Module 8 uses both.
• The dns filter shows nothing at all in step 9. Your terminal queries went to a resolver over an encrypted transport (some OS setups do this now) or Wireshark is on the wrong interface — recheck the interface with the moving graph, and try nslookup again while capturing.
• Step-10 conclusion feels uncertain. Browsers cache aggressively too — a site visited recently needs no new lookup. Test with a site you have not visited today.

Reset/cleanup. Nothing was changed. Keep your six finds — the capstone's documentation phase includes a DNS inventory, and this is its rehearsal.

Check yourself

1. Put these four parties in the order they are consulted when a completely uncached name is resolved: TLD server · stub resolver's recursive resolver · authoritative server · root server. Then state which one finally holds the answer.
2. A user says: "The website moved to a new host yesterday; some visitors see the new site, some still get the old one." Explain the mechanism in two sentences, naming the field responsible.
3. Match each task to the record type that answers it: (a) find the IPv6 address of a host · (b) find which servers accept a domain's mail · (c) prove to a service that you control a domain · (d) discover a domain's authoritative servers · (e) point shop.example.com at an external platform's hostname.
4. Why does the DNS hierarchy scale to hundreds of millions of domains when a flat directory could not? Answer using either of the book's two analogies, retold in your own words.
5. A security team reviews firewall logs expecting to see all staff DNS queries on port 53, but finds a large share of lookups invisible. What happened, which two ports are now involved, and why does one of them tell the team almost nothing?
6. In your lab capture, the DNS query rode inside a UDP datagram, not a TCP segment. Using last lesson's decision rule, justify that design choice.

Answers

1. Recursive resolver → root server → TLD server → authoritative server; the authoritative server holds the actual records — everyone above it only knows who to ask next.
2. DNS answers are cached with a TTL; resolvers that fetched the old address before the change will keep serving it until that TTL expires, while fresh lookups get the new one. Nothing "propagates" — caches simply expire on their own schedules.
3. (a) AAAA · (b) MX · (c) TXT · (d) NS · (e) CNAME.
4. Delegation: like the family tree, no one holds the whole census — each level knows only its children and who to ask next, so the data, the load and the administration are split across millions of independently run branches. One phone book would centralize all three, and collapse.
5. Browsers and some OS setups moved lookups to encrypted DNS: DoT on port 853 and DoH on port 443. DoT at least is visibly DNS; DoH is indistinguishable from ordinary HTTPS on 443 — the universal door — so the team sees "some HTTPS" and learns nothing about names.
6. A DNS lookup is one small question and one small answer — deadline-hungry rather than guarantee-hungry: better to retry a lost query than to pay a three-segment handshake before every lookup. UDP fits exactly (with the application retrying when needed).

Key terms

• DNS (Domain Name System) — the delegated, hierarchical directory translating names to addresses (and more).
• Name resolution — the act of translating a name into the address packets need.
• FQDN — a fully qualified domain name; read right to left: TLD → domain → host/alias.
• Root servers / TLD servers / authoritative servers — the tree's three tiers; authority is delegated downward, answers live at the bottom.
• Stub resolver / recursive resolver — your machine's minimal asker, and the middleman that does the tree-walk for it.
• Recursive vs. iterative query — "get me the final answer" vs. "tell me who to ask next"; your machine asks recursively, the resolver walks iteratively.
• Cache / TTL — stored answers, and the per-record countdown governing how long they may be reused.
• A / AAAA / CNAME / MX / TXT / SRV / SOA / NS — the everyday record vocabulary (address, IPv6 address, alias, mail, text/policy, service, authority data, delegation).
• DoT (port 853) / DoH (port 443) — encrypted DNS transports; the reason modern captures show fewer cleartext lookups.
• nslookup / dig — the hand tools for querying DNS directly, by record type.

Summary

• Humans use names, packets need addresses; DNS translates — the book's phone-book analogy, still exact.
• A flat directory cannot scale; DNS is the book's family tree formalized: root → TLD → authoritative, each level delegating to its children, nobody holding the whole map.
• Your machine asks one recursive question; a resolver walks the tree iteratively; caching with TTLs makes the whole system fast and explains why changes take time to be seen everywhere.
• Records are typed: A/AAAA for addresses, CNAME for aliases (the book's "CN," kindly completed), MX for mail, TXT for policy and proofs, SRV for services, NS/SOA for the tree's own bookkeeping.
• Encrypted DNS arrived: DoT on 853, DoH inside 443 — closing the last big cleartext leak and thinning the DNS visible in captures; command-line tools still speak classic port 53.
• You resolved six records of five types by hand, watched query/response pairs live in Wireshark, and tested whether your own browser has already gone dark.

Next lesson

DNS assumed every machine already has an address — but where did it come from? Almost certainly nobody typed it. The next lesson meets DHCP, the service that leases addresses automatically, and captures its famous four-message ritual on your own network.

Sources and further study

• Al-Doori, T., Network Essentials, Chapters 4, 5 and 10 — the DNS server, the FQDN, the flat-file-to-tree story, and the nslookup craft this lesson modernizes.
• RFC 1034, "Domain Names — Concepts and Facilities" — https://www.rfc-editor.org/info/rfc1034/ — the founding design: delegation, caching, record types.
• Cloudflare Learning Center, "What is DNS?" — https://www.cloudflare.com/learning/dns/what-is-dns/ — a well-maintained visual retelling of the resolution journey.
• RFC 7858, "Specification for DNS over TLS" — https://www.rfc-editor.org/info/rfc7858/ — DoT, the encrypted transport on port 853.
• RFC 8484, "DNS Queries over HTTPS (DoH)" — https://www.rfc-editor.org/info/rfc8484/ — DoH, DNS through the universal door.
• Download: OSI and TCP/IP Model Reference (DNS is an application-layer service riding transport you can now name).