DNS In Depth

host1 already covers DNS practically — adding records at a registrar, moving DNS to Cloudflare. This chapter doesn't repeat that; it goes underneath it, to the actual protocol-level mechanics host1 never needed to explain.

What host1 Already Covered (And What This Chapter Adds)

host1 is about managing DNS records — creating an A record, pointing a domain at a new host. This chapter assumes that part is already familiar and instead explains what actually happens, step by step, the moment a DNS query gets made — a resolution process host1 never walked through.

The DNS Hierarchy — Root, TLD, Authoritative

DNS is a hierarchical, distributed database, not one central lookup table anywhere. Three tiers matter: root servers (13 logical root server clusters worldwide, knowing only where to find TLD servers), TLD servers (one set per top-level domain — .com, .org, .net — knowing where to find authoritative servers for domains under that TLD), and authoritative servers (holding the actual records for one specific domain — e.g. the nameservers a domain's own registrar or Cloudflare setup in host1 points to).

The Resolution Process, Step by Step

Resolving www.example.com from scratch, assuming nothing is cached anywhere:

1. The application asks the operating system's own stub resolver.
2. The stub resolver asks a recursive resolver — the ISP's own DNS server, or a public one like 8.8.8.8 or 1.1.1.1.
3. The recursive resolver asks a root server: "who handles .com?"
4. The root server responds with the address of a .com TLD server.
5. The recursive resolver asks that TLD server: "who is authoritative for example.com?"
6. The TLD server responds with example.com's own authoritative nameservers.
7. The recursive resolver asks that authoritative nameserver directly: "what is the A record for www.example.com?"
8. The authoritative server responds with the actual IP address.
9. The recursive resolver caches the answer and returns it up the chain to the stub resolver, and finally to the application.

This full chain usually takes only milliseconds, and is almost always shortened dramatically by caching at multiple levels along the way — covered next.

Caching and TTL

Every DNS record carries a TTL (time to live) — how long a resolver is allowed to cache the answer before it has to ask again. This is exactly why a DNS change (updating an A record after moving hosts, per host1's own material) doesn't take effect everywhere instantly — cached copies at resolvers scattered around the world keep serving the old answer until their own individual TTL expires. This is the concrete mechanism behind a genuinely common source of confusion: "I changed my DNS and nothing happened."

Record Types, Beyond A

host1 already covers using several of these practically — this table is the formal, precise reference definition underneath that practical usage.

Why DNS Mostly Uses UDP

Revisiting net1-7's own closing note directly: a typical DNS query and response is small, and UDP's complete lack of handshake overhead (no three-way handshake, per net1-7) makes a single query dramatically faster than establishing a full TCP connection just to ask one small question. TCP fallback happens specifically when a response is too large for a single UDP packet (historically capped at 512 bytes, extended by EDNS0) or during zone transfers between authoritative servers themselves.

Hands-On Exercises