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 unit, 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

This section’s Tools at a Glance

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:

1. Your PC searches first: it checks its own memory (cache) and the hosts file.
2. It asks the DNS server: if it doesn’t know, it asks the configured DNS server (usually set by your router or ISP).
3. The recursive resolver returns a final answer or error. It may answer from cache, forward the request, or follow referrals through iterative queries to root, TLD, and authoritative servers.
4. 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 book01.invalid here, this computer will go straight to 127.0.0.1 for book01.invalid 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 this section’s experiment.

3. Follow Along

Before you begin. A recursive resolver can answer from cache, forward to another resolver, or perform iterative queries. nslookup queries DNS and does not test the full application resolver path. Browser DNS-over-HTTPS, proxies, caches, and hosts processing can differ.

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

Illustrative output. Values, wording, account names, and available fields vary by environment.

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 the responding server is not answering authoritatively for that name. This label alone does not prove the data was already cached before your request.

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
            ...

Illustrative output. Values, wording, account names, and available fields vary by environment.

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

Illustrative output. Values, wording, account names, and available fields vary by environment.

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.”

Repeat the lookup and record the resolver, record type, address, TTL, and time. A cached TTL may count down, but a refresh, a different cache node, or another answer can increase it. The next example illustrates why two TTL values alone are not conclusive.

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

Illustrative output. Values, wording, account names, and available fields vary by environment.

A TTL rising from 32 to 108 over 20 seconds does not by itself prove expiration of that original entry: 20 seconds is less than 32. A refreshed answer or a different cache/backend is also possible. Record the evidence without choosing a cause prematurely.

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

Illustrative output. Values, wording, account names, and available fields vary by environment.

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   book01.invalid

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

ping book01.invalid

Pinging book01.invalid [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 book01.invalid 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 book01.invalid

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.

Illustrative output. Values, wording, account names, and available fields vary by environment.

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.

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

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

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

Practice a diagnostic sequence using only this section’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 (Illustrative source example: 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

1. Query naver.com, daum.net, and github.com with nslookup and write down the addresses
2. 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)
3. Pick one name with Resolve-DnsName, record its TTL, then query again 1–2 minutes later and record the change
4. 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?

[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

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 (Illustrative source example):

*** kns.kornet.net can't find book01.invalid: 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 book01.invalid. Please check the name and try again.” (Illustrative source example).

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: compare the current hosts file with the original saved before the exercise. Confirm only the practice entry was added and then removed. A failed ping lookup alone is not proof that the complete file was 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 subsection 3-8 (connection → address → DNS → program) from the lower floors up.

7. Summary

This section’s Concepts

This section’s Commands

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 this section’s security harvest.

Once every box is checked, Step 33 is complete.