Lesson text for this page (click to expand)

DNS

Lessons (6, study in order)

Lesson 1 · Domain names are for humans, IPs are for machines

Beginner · about 8 min

Goal: Understand exactly what problem DNS solves, and the hierarchical structure of domain names.

Why DNS exists

Machines talk to each other using IP addresses, but a number like 203.0.113.10 is hard for humans to remember.

DNS (Domain Name System) is that translation layer:
it translates names humans can remember into IPs machines need to use.

★ This is also a connection point left over from the "Layer 3 static routing" module: that module covered "how a packet moves once it has an IP," this module covers "where the IP comes from."

★ Domain names are read right-to-left, top-down from the root

Breaking down www.example.com.:

.          <- Root, the rightmost one is usually omitted when typing
   com.           <- Top-level domain (TLD)
example.com.      <- Second-level domain
www.example.com.  <- Hostname/subdomain

★★ That trailing dot is not a typo -- it represents the root domain itself. It's usually omitted in everyday typing, but a domain name in the protocol really is a string of labels counted "down from the root."

★ Any level can be delegated to a different server -- that's the topic of the next lesson.

Try it: watch a full resolution walk through every level

Go to the resolution simulation page and look up www.example.com.

★ Watch every level it passes through: local -> cache -> Root -> TLD -> authoritative server.

Key takeaways

  • ★ DNS is the "domain name -> IP" translation layer -- humans remember names, machines use IPs
  • ★★ A domain name counts down from the root: . -> com. -> example.com. -> www.example.com.
  • The trailing dot represents the root domain itself, it's not a typo

Lesson 2 · ★★ Recursive vs. iterative queries

Beginner · about 10 min

Goal: Understand what happens between "the client asks only once" and "the resolver has to ask several times."

★★ Two kinds of "asking," with completely different meanings

Recursive query: "Tell me the final answer, I don't care how you get it."
This is what a client does when it asks a resolver -- sends it once, and waits for the final result.

Iterative query: "Tell me whatever you know, and if you don't know, tell me who to ask."
This is what a resolver does when it asks root / TLD / authoritative servers -- each one either gives an answer or a referral, and never says "I'll keep looking for you."

★★★ Key point: root / TLD / authoritative servers never talk to each other directly

All of the "grunt work" is done by the resolver, alone:

resolver -> Root          asks once
resolver -> TLD(.com)     asks again
resolver -> auth server   asks again

★★ All three of these are sent directly by the resolver -- root does not ask the TLD on your behalf, and the TLD does not ask the authoritative server on your behalf.
Each of them just gives a "referral," and the resolver personally asks the next one.

★ This is completely different from layer-3 routing: routers forward the same packet hop by hop; here, the same asker repeatedly asks directly, and the middlemen never forward anything.

Try it: count how many times it asks

Go to the resolution simulation page, look up www.example.com, and step through "who asked whom" at each hop.

★ Notice the "asked by" column at every hop -- it's always the same resolver.

Key takeaways

  • ★★ Recursive query: sent once, waits for the final answer (client -> resolver is this kind)
  • ★★ Iterative query: wants an answer or a referral, never does the work for you (resolver -> root/TLD/authoritative is this kind)
  • ★★★ The resolver asks level by level, directly, itself -- the middlemen never forward for each other

Lesson 3 · ★★★ Authoritative / recursive / forwarding: three capabilities

Advanced · about 12 min

Goal: This is the core of the whole module: three independent switches that can be combined on the same server.

Three capabilities, each answering a different question

| Capability | The question it answers |
|---|---|
| Authoritative | "This namespace is mine to manage, I have the real answer" |
| Recursive | "If I'm not authoritative, I'll go ask level by level myself" |
| Forwarding | "If I'm not authoritative, I'll hand the whole question to someone else, as-is" |

★★★ These three are independent switches, not a pick-one-of-three. A server can absolutely be "authoritative for A + forwarding for B" at the same time.

★★ The most common real-world config: enterprise internal DNS

A company's internal network typically configures a DNS server like this:

· Authoritative for corp.internal. (names for internal systems)
· Has a forwarder configured (to the ISP, or a public recursive server like 8.8.8.8)

The result: the same server answers internal names authoritatively and forwards the whole query for external names --
employees only ever need to configure this one DNS address, no matter what they're looking up.

★ Forwarding vs. recursion: the difference is "who does the iterative querying"

Both are solutions to "what to do when I'm not authoritative," but different parties do the work:

· Recursion: it asks root/TLD/authoritative servers itself -- the iterative querying is done by itself
· Forwarding: it throws the whole question at an upstream server -- the iterative querying is done upstream, it's just a "courier"

★ The benefit of forwarding: the internal server doesn't need to know any root server addresses, and doesn't have to carry the cost of recursion itself -- all of that is handed to upstream.

Try it: same server, two different reactions

Current scenario: ② Forwarding vs. recursion. Go to the resolution simulation page:

(1) Look up app.corp.internal -- InternalDNS hits authoritatively, answers directly
(2) Look up www.example.com -- InternalDNS forwards the whole question to Resolver1, and Resolver1 does the actual recursion

★★ Same server, but which path it takes depends entirely on which name is being asked.

Key takeaways

  • ★★★ Authoritative / recursive / forwarding are three independent switches that can be combined
  • ★★ Most common in production: authoritative for internal names + forwarding external queries -- only one DNS address to configure
  • ★ Forwarding and recursion are both solutions to "what if I'm not authoritative" -- the difference is who does the iterative querying

Lesson 4 · ★★ Local hosts file and caching

Advanced · about 10 min

Goal: Understand "no lookup needed at all" versus "looked up once, remembered for a while" -- and why a DNS change doesn't always take effect immediately.

★★ The local hosts file: no lookup needed at all

Before sending a query to any server, a client first checks its local hosts file -- if the name is hardcoded there, it's used directly, zero network packets.

⚠️★★ This is also the most common reason for "I changed the DNS record, but it still resolves to the old address": the hosts file never updates alongside DNS records -- it's a completely independent, static list.

★ Caching: looked up once, remembered for a while

Every time a resolver successfully gets an answer, it stores a cached copy until the TTL expires.

★★ The next time anyone asks for the same name, it's served straight from cache -- the delegation chain is never walked again.

★ The TTL is decided by the authoritative server and written into the record -- the shorter the TTL, the faster a change propagates across the network, but the lower the cache hit rate.

Try it: look up a "stale" answer

Current scenario: ④ Local hosts override. PC-Stale's hosts file hardcodes an IP that differs from the real authoritative record.

Go to the resolution simulation page and look up www.example.com -- see whether it skips the lookup entirely and just returns that "old" answer.

Key takeaways

  • ★★ The hosts file has the highest priority, and never auto-updates alongside DNS records
  • ★ A cache hit never walks the delegation chain again -- that's the entire point of caching
  • The TTL decides how long it takes for a change to be visible network-wide

Lesson 5 · ★★ NXDOMAIN vs. refused: two kinds of "no answer"

Troubleshooting · about 10 min

Goal: These two failures look alike but mean completely different things -- telling them apart saves a lot of troubleshooting time.

★★ NXDOMAIN: the domain really doesn't exist (a valid answer)

The server that was asked really is authoritative for this namespace, but there's no such record in it.

★ This isn't a failure -- it's a definitive, complete answer: "no such name." This is what you see when a browser is given a typo'd URL.

★★ Refused: this server can't help you

The server that was asked is neither authoritative for this name, nor has recursion enabled, nor has a forwarder configured -- it has no way to answer, and refuses outright.

★★★ The most common cause: the resolver is misconfigured, pointing directly at a server that's only authoritative for its own zone (e.g. mistakenly entering an authoritative server's address as if it were a public DNS address).

Try it: compare the two failures

(1) Scenario ⑤ Domain does not exist: look up nope.example.com -- it gets all the way to the authoritative server, which really does manage this zone, but has no such record -> NXDOMAIN

(2) Scenario ③ Authoritative-only, refuses to recurse: PC-Bad's resolver points directly at the authoritative server Auth1. Looking up anything Auth1 isn't authoritative for -> Refused

★ Both are "didn't get an IP," but the cause is completely different, and so is the fix.

Key takeaways

  • ★★ NXDOMAIN: reached the authoritative server, it really has no such record -- a valid answer
  • ★★ Refused: the server is neither authoritative, nor recursive, nor has a forwarder -- it can't help
  • ★★★ The most common cause of Refused: the resolver is misconfigured, pointing directly at an authoritative server

Lesson 6 · ★ Delegation is configured, not discovered by a protocol

Advanced · about 10 min

Goal: Where delegation relationships come from -- and why they can happen at any level.

★ Delegation can happen at any level, not a fixed three tiers

"root -> TLD -> authoritative" is just the most common three tiers, not a hardcoded rule.

An authoritative server can absolutely delegate a slice of the namespace it manages further down -- for example, the admin of example.com. can hand the entire dev.example.com. slice off to another server.

★★ Every extra level of delegation means one more question during resolution -- how deep the chain can go depends on configuration, not a protocol limit.

★★ "Who manages which slice" is written into zone files by hand

NS records (delegation) and A/CNAME records (answers) are both hand-written into zone files by an administrator -- no protocol helps discover or sync this ownership information for you.

★★ ⚠️ Note this is not the same thing as a "control plane" -- DNS has no routing-protocol-style split between control plane and data plane at all:
it only has ordinary query/response packets (the ones you see on the "resolution simulation" page), with no separate signaling protocol dedicated to syncing "who manages which slice."
This ownership information is purely static configuration -- it doesn't even rise to the level of a "control plane."

Try it: watch a 4-level delegation

Current scenario: ⑥ Multi-level delegation. Look up api.dev.example.com -- count how many levels of delegation it goes through (hint: one more than the default scenario).

Key takeaways

  • ★ Delegation can happen at any level -- not a fixed "root/TLD/authoritative" three tiers
  • ★★ "Who manages which slice" is written into zone files by hand -- no protocol syncs it for you
  • ★★ DNS is not a routing protocol and has no control-plane/data-plane split -- only ordinary query/response traffic