Step 33. DNS — The Internet’s Phone Book

Level 0 — Understanding Computer Operation and Structure | Difficulty ★★★☆☆ | Estimated time: 3 hours

Prerequisites: Steps 31–32 (IP, ARP) complete. Work in Windows PowerShell. Administrator rights are needed only for the hosts file experiment.

What you need: a Windows PC, PowerShell, and (for the hosts experiment) Notepad running as administrator.
Caution: Lookup commands are safe. There is one experiment that modifies the hosts file, and you must restore it afterward — the procedure includes restore and verification steps.

Every day you type naver.com and google.com. But as you learned in the last two chapters, computers communicate in numbers (IP addresses). The letters "google.com" can’t be used for communication. So who converts these names into numbers?

That job belongs to a giant worldwide phone book called DNS (Domain Name System). If this phone book stops, the internet effectively stops too — people can’t go around memorizing "142.251.118.101." Today you’ll throw questions directly at this phone book, and even lay hands on the small manual phone book inside your PC (the hosts file).

1. Learning Objectives

By the end of this chapter, you will be able to:

Explain that DNS is a hierarchical system that converts "name → IP"
Describe in five steps what happens between typing an address in a browser and getting an IP
Query names yourself with nslookup and Resolve-DnsName and read the answers
Explain what TTL is and watch it decrease with each lookup
Explain the priority and dangers of the hosts file, and verify restoration after the experiment

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	PowerShell 5.1. Administrator Notepad used once for the hosts experiment
Today’s commands	`nslookup name [server]`, `Resolve-DnsName name`, `ipconfig /flushdns`, `Get-Content …\etc\hosts`
Concepts needed	Domain hierarchy, recursive query, DNS cache and TTL, A record, hosts file priority

2-1. The Hierarchy of Names — Reading an Address Backwards

A domain name is a hierarchy divided by dots (.). But the reading direction is the opposite of an address. In www.example.co.kr, the right side is the larger unit.

www   . example   . co   . kr
(host)  (organization) (company) (Korea)

At the top is the root, the world’s highest-level phone book; below it sit top-level domains (TLDs) like .kr and .com; and below those hang each organization’s name. Think of the phone book not as a single volume but as an organization divided by ranks.

2-2. Recursive Queries — When You Don’t Know, Ask Upward

What happens when you type google.com:

Your PC searches first: it checks its own memory (cache) and the hosts file.
It asks the DNS server: if it doesn’t know, it asks the configured DNS server (usually set by your router or ISP).
The DNS server finds it for you: if that server doesn’t know either, it asks along the ranks — root → .com → google — until it gets an answer. This is a recursive query.
It answers and remembers: it tells you the IP and remembers it briefly for next time.

In other words, you don’t ask the world’s most authoritative server every time; you ask a "librarian who looks things up for you," and that librarian follows the hierarchy.

2-3. TTL — The Expiration Time of Memory

Every DNS answer comes with a number called TTL (Time To Live). It’s the validity period: "how many seconds you may remember this answer." The TTL of a cached answer ticks down one second at a time, and when it hits zero, the answer is discarded and the question is asked again.

Thanks to TTL, the world stays fast without repeating the same question. Conversely, when a site changes its address, a computer remembering the old answer keeps going to the old address until the TTL expires. This "memory lag" comes up again in the experiments and exercises below.

2-4. The hosts File — The Note in Your Desk Drawer

In step 1 of section 2-2, we said "your PC searches first." One of the things it checks is the hosts file — a manual phone book inside your computer that is consulted before DNS. If you write 127.0.0.1 test.local here, this computer will go straight to 127.0.0.1 for test.local without ever asking DNS.

The hosts file is older than DNS. In the internet’s predecessor era, when there were only a few dozen computers, everyone simply downloaded one central hosts file — that was the whole system. When computers multiplied, DNS appeared, but one rule remained: "the note in my drawer outranks the official phone book."

Administrators use this file for development and testing. But what if that priority is abused? If someone writes naver.com with a fake IP, the user types the correct name and ends up at a fake site. This is the classic hosts poisoning attack (a form of pharming). That’s why you must restore everything after today’s experiment.

3. Follow Along

3-1. Asking for a Name — nslookup

nslookup naver.com

Server:  kns.kornet.net
Address:  168.126.63.1

Non-authoritative answer:
Name:    naver.com
Addresses:  223.130.200.219
            223.130.192.247
            223.130.192.248
            223.130.200.236

(Measured 2026-09-09. Your DNS server and the addresses you receive may differ.)

How to read the output: the top part (Server/Address) is "who did we ask" — right now it’s the ISP’s DNS server (the librarian). The bottom part (Name/Addresses) is the answer we received. Notice there are four addresses — large services attach multiple addresses to one name to spread connections across many servers.

Non-authoritative answer means "this answer didn’t come from the server that owns the domain; it answered from what it remembered." It’s a normal answer that came from the cache.

3-2. Asking a Different Librarian

Append a server address after the command to change librarians. 8.8.8.8 is a public DNS run by Google.

nslookup google.com 8.8.8.8

Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    google.com
Addresses:  172.217.213.139
            172.217.213.138
            172.217.213.101
            ...

(Measured 2026-09-09.)

How to read the output: the librarian has changed to dns.google (8.8.8.8). Yet when we asked the default librarian (the ISP DNS) the same day, we got addresses in the 142.251.118.x range — the two librarians answered differently!

This is not a malfunction. Giant services like Google keep servers all over the world, and give different server addresses depending on the librarian’s memory (cache) and location. "Different answers" doesn’t immediately mean "poisoned," but take away the instinct that the difference itself is a starting point for investigation.

3-3. Watching the TTL Tick Down — Resolve-DnsName

There’s also a command that shows results as a table, in proper PowerShell style.

Resolve-DnsName naver.com -Type A | Format-Table Name, Type, TTL, IPAddress

Name      Type TTL IPAddress
----      ---- --- ---------
naver.com    A 157 223.130.192.247
naver.com    A 157 223.130.192.248
naver.com    A 157 223.130.200.219
naver.com    A 157 223.130.200.236

(Measured 2026-09-09.)

How to read the output: Type A marks the kind of answer (record) — "name → IPv4 address" — and TTL 157 means "this answer will be remembered for another 157 seconds."

Run the same command again a little later and the TTL will have decreased. In our measurement, we ran it twice 20 seconds apart:

First lookup: TTL 32
(20 seconds later)
Second lookup: TTL 108

(Measured 2026-09-09.)

How to read it: at the first lookup, the cache held an answer with only 32 seconds left; in between, it expired, and what we saw was a freshly fetched answer (108 seconds). "TTL ticks down, and at zero you ask again" is now confirmed in numbers. Try the same command twice yourself, with a gap in between.

3-4. Opening the hosts File

The hosts file lives at C:\Windows\System32\drivers\etc\hosts. Let’s just read it first (reading works with normal privileges):

Get-Content C:\Windows\System32\drivers\etc\hosts

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
# ...
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost

(Measured 2026-09-09. Some of the English explanation lines in the middle were shortened. On the measured computer there were also a few lines below, managed automatically by a VPN program — your file may also contain lines added by installed programs.)

How to read the output: every line starting with # is a comment and has no effect. A default hosts file is effectively an empty phone book — nothing written is normal. If you see an actual entry line that doesn’t start with #, it’s worth checking who wrote it and why.

3-5. The hosts Experiment — Feeling the Power of the Note

⚠️ This experiment modifies a system file. Follow the steps in order, and restore everything at the end.

In the Start menu, right-click Notepad → Run as administrator, and from that Notepad open C:\Windows\System32\drivers\etc\hosts. Add a new line at the very bottom:

127.0.0.1   test.local

Save and close (if saving fails, you didn’t open Notepad as administrator). Now verify:

ping test.local

Pinging test.local [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

(Output example — this experiment is a step you perform yourself with administrator rights.)

How to read it: the nonexistent name test.local resolved to 127.0.0.1 (yourself — the loopback from Step 31). Without asking DNS at all, the computer followed the note in its drawer.

Mandatory — restore: open hosts again in administrator Notepad, delete the line you just added, and save. Then verify:

Get-Content C:\Windows\System32\drivers\etc\hosts
ping test.local

If the line is gone from the file and ping says it can’t find the host, restoration is complete. In professional practice the language is not "I deleted it" but "I verified it."

Why: the point of this experiment is not "it works" but priority. hosts > DNS. You’ve confirmed with your own hands how powerful this one line is — and therefore why this file becomes an attacker’s target.

3-6. Emptying the Cache — ipconfig /flushdns

This command throws away every DNS answer sheet your computer was remembering.

ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

(Measured 2026-09-09. On Korean Windows it appears as something like "DNS 확인자 캐시를 플러시했습니다" — "DNS resolver cache flushed.")

How to read it: this is the emergency fix for when a site changed its address but you keep connecting to the old one. Emptying the cache makes the next lookup ask the librarian anew. The hosts file is not erased by this command — hosts is a configuration file, not a cache.

3-7. Practice Saying It in Five Steps

Say out loud the journey of the moment you type www.example.com into a browser and press Enter.

It searches my cache and the hosts file.
If not found, it asks my DNS server (the librarian).
The librarian follows the ranks (root → TLD → organization).
It receives the answer (IP) and remembers it.
It connects to the web server at that IP.

If these five sentences come out without stumbling, you’ve achieved half of today’s chapter.

3-8. Diagnosis Practice — "The Internet Isn’t Working"

Practice a diagnostic sequence using only today’s tools. The key is the combination of two questions: "Does it work by number? Does it work by name?"

Scenario A — suspect DNS: ping 8.8.8.8 gets replies (measured 2026-09-09: replies confirmed at 33 ms), but ping google.com fails.

→ Diagnosis: numbers work, names don’t. The connection is alive and the phone book is broken — a DNS problem. Checking the configured DNS server, or temporarily switching to a public DNS (8.8.8.8), often fixes it.

Scenario B — suspect the connection itself: even ping <gateway> gets no reply.

→ Diagnosis: a problem before names, a failure of the physical connection. Start with the cable and Wi-Fi connection. No amount of fiddling with DNS helps at this stage.

How to read it: "from the lower floors upward" is the iron rule of diagnosis. Connection (floor 1) → address and gateway (floor 2) → DNS (floor 3) → program (floor 4).

4. Missions & Exercises

Mission — Build a DNS Investigation Card

Query naver.com, daum.net, and github.com with nslookup and write down the addresses
Ask the 8.8.8.8 librarian for the same three names and compare with the default librarian’s answers (were any different? If so, write one line on why they can differ)
Pick one name with Resolve-DnsName, record its TTL, then query again 1–2 minutes later and record the change
Organize everything into dns-card.txt

Exercises

Q1. Say in order the five steps from typing an address in a browser to getting an IP.

Q2. On one computer, typing naver.com leads to a strange site. On the computer next to it, it’s normal. What file should you suspect first, and why?

Q3. What does ipconfig /flushdns erase, and why doesn’t this command erase the hosts file’s contents?

Q4. You received a report: "ping 8.8.8.8 works but ping google.com doesn’t." Which layer’s problem is this, and what will you check next?

5. Model Answers & Completion Criteria

Mission Model Answer

Example from the measured computer (2026-09-09):

[Default librarian: 168.126.63.1 (ISP DNS)]
naver.com   → 223.130.200.219 plus 3 more
google.com  → 142.251.118.101 plus several more

[8.8.8.8 librarian (dns.google)]
google.com  → 172.217.213.139 plus several more  ← address differs from default librarian
Reason for the difference: large services split addresses across many servers,
             and librarians answer differently depending on cache and location (normal)

[TTL observation: naver.com]
1st lookup TTL 32 → (20 seconds later) 2nd lookup TTL 108
Interpretation: the cached answer expired and a freshly fetched answer is shown

How to verify: ① Did all three names return IPs as numbers? ② Is the two-librarian comparison table filled in? ③ Are the two TTL numbers recorded — either decreased (still in cache) or increased again (re-fetched); both are normal. The core of this mission is that a different address is not a wrong answer but an observation point.

Exercise Solutions

Q1 solution. ① Search my cache and the hosts file → ② If not found, ask my DNS server → ③ That server looks it up along root → TLD → organization (recursive query) → ④ Receive the answer (IP) and remember it for the TTL → ⑤ Connect to the web server at that IP.

Q2 solution. That computer’s hosts file. Because hosts is a per-computer manual phone book consulted before DNS, it’s possible for only one machine to be poisoned. Check with Get-Content C:\Windows\System32\drivers\etc\hosts for any line that doesn’t start with #. The neighboring computer being normal means "the world’s phone book is fine; only this computer knows differently," so the investigation narrows to inside your computer.

Q3 solution. It’s a command that throws away all DNS answers the computer remembered (the resolver cache). The hosts file is a configuration file on disk, not a cache, so it’s not this command’s target — cache is memory (disappears on its own past the TTL), hosts is configuration (permanent until you delete it yourself).

Q4 solution. The connection (floors 1–2) is alive and name resolution (floor 3) is broken — a DNS problem. Next checks: ① See whether the librarian answers with nslookup google.com. ② If not, ask another librarian with nslookup google.com 8.8.8.8 — if that works, your default DNS server is broken; if that also fails, widen the scope to an upstream connection problem.

Completion Criteria Checklist

[ ] I can say the five steps from entering a browser address to getting an IP
[ ] I can distinguish "who did we ask" from "the answer received" in nslookup output
[ ] I can query with a specified librarian (… 8.8.8.8)
[ ] I know what TTL means and observed its change across two lookups
[ ] I can explain the priority and dangers of the hosts file
[ ] If I did the hosts experiment, I verified restoration with Get-Content and ping
[ ] Mission: I completed dns-card.txt

6. Common Pitfalls & Fixes

Wall 1. "I edited hosts but it won’t save."

Symptom: on saving, you get "Access is denied."

Cause: hosts is a system file and can’t be modified with normal privileges. It’s a flagship file protected by the principle of least privilege.

Fix: run Notepad as administrator (right-click in the Start menu), then open the file from inside it. Privileges don’t rise in a window where the file was opened first.

Wall 2. "I typed a nonexistent name and got a strange answer / nslookup’s answer has two parts."

Symptom: querying a nonexistent name shows a message like this (measured 2026-09-09):

*** kns.kornet.net can't find test.local: Non-existent domain
Server:  kns.kornet.net
Address:  168.126.63.1

Cause: the top is "the librarian’s answer" (no such name), the bottom is "who answered." Once you know the reading order, it’s not an error but a normal negative response. Pinging the same name prints "Ping request could not find host test.local. Please check the name and try again." (measured 2026-09-09).

Fix: Non-existent domain is a clean failure meaning "that name exists nowhere in the world." Check for typos first.

Wall 3. "I edited hosts but it’s not taking effect."

Symptom: you added a line but ping behaves as before.

Cause: the order of suspicion is threefold. ① Did the save actually happen (administrator rights)? ② Did you type the name exactly (spaces, typos)? ③ Browsers sometimes use their own cache and can behave differently from ping.

Fix: ping uses the system’s name resolution, so it’s a good verification tool where hosts applies immediately. After saving, check with ping first.

Wall 4. "I’m anxious about whether I restored hosts after the experiment."

Symptom: you can’t remember whether you deleted the line.

Cause: edits made during practice are easy to lose track of.

Fix: see it with your own eyes via Get-Content C:\Windows\System32\drivers\etc\hosts. If there are no unfamiliar lines besides # comments and legitimate entries you know, you’re fine. And if the final verification ping from section 3-5 says "could not find," it’s restored.

Wall 5. "nslookup works but the internet doesn’t (or vice versa)!"

Symptom: name lookups work but connections don’t, or IPs work but names don’t.

Cause: this combination is the key to diagnosis. IP works but name doesn’t = DNS problem. Both fail = connection problem.

Fix: always ask these two questions as a set: "Does it work by number? Does it work by name?" Climb the ladder from section 3-8 (connection → address → DNS → program) from the lower floors up.

7. Summary

Today’s Concepts

Concept	One-line description
DNS	A worldwide hierarchical phone book that converts names to IPs
Recursive query	The librarian (DNS server) looks it up for you along the ranks
A record	The "name → IPv4 address" answer type (AAAA is IPv6)
TTL	Validity time (seconds) of a cached answer — ticks down, re-queried at zero
Cache	Temporary memory of answers once obtained (emptied with `ipconfig /flushdns`)
hosts file	The manual phone book consulted before DNS — powerful and dangerous
Non-authoritative answer	A marker that the answer came from cache, which is normal

Today’s Commands

Command	What it does
`nslookup name`	Query the default DNS server for a name
`nslookup name 8.8.8.8`	Query with a specified librarian
`Resolve-DnsName name -Type A`	Query in a table including TTL
`ipconfig /flushdns`	Empty the DNS cache
`Get-Content …\drivers\etc\hosts`	View hosts file contents (read)

The Instinct That Matters More Than Commands

"Does it work by number? Does it work by name?" — these two questions are the first fork of network diagnosis. A one-line complaint like "the internet isn’t working" can now be translated into "which layer’s problem is it?"

And remember: many hands (cache, hosts, the librarian, the servers of the hierarchy) touch the road from name to number, and if one of them is poisoned, the user’s screen shows nothing unusual. That you can be fooled even after typing the correct name in the address bar — knowing that is today’s security harvest.

Once every box is checked, Step 33 is complete. Click the checkbox in the sidebar to save your progress.