How DNS Works

Computers talk over IP addresses, but humans remember names. DNS is the distributed phone book that turns www.example.com into an IP. You can't debug Kubernetes networking (Day 31+) until you understand the plain-internet DNS flow first: who answers, what gets cached, and which files decide the result.

Solution: Resolve names by walking the stub then recursive resolver then root/TLD/authoritative chain, caching at each hop for the record's TTL.

People remember names, but phones connect on numbers, so directory enquiries keeps a master phone book and an operator who, given a name, hunts down the matching number for you. DNS is exactly that for the internet: a recursive resolver is the operator that takes a hostname like www.example.com, walks the authoritative phone book, and hands back the IP address your machine actually dials.

The same cluster entities appear in every day's notes; the diagram below shows where this day's topic fits.

A name is resolved by walking a hierarchy: your stub resolver asks a recursive resolver, which (if nothing is cached) walks the root -> TLD -> authoritative servers.

Graph legend — each node is a real step resolving www.example.com:

Putting it together, here is what happens when you type a URL into the browser and the name has not been cached yet.

A DNS zone holds several kinds of records, each answering a different question about a name; these are the ones you will meet most often.

   A      name -> IPv4              www.example.com -> 93.184.216.34
   AAAA   name -> IPv6              www.example.com -> 2606:2800:220:1:...
   CNAME  alias -> another name     shop.example.com -> www.example.com
   NS     which servers are authoritative for a zone
   MX     mail servers for a domain
   TXT    free text (SPF, domain verification, ACME challenges)
   PTR    IP -> name (reverse DNS)
   SRV    service location (host + port) — used heavily inside Kubernetes

The order the OS resolves a name is configurable, and /etc/hosts is checked before DNS for most setups.

cat /etc/hosts          # static name -> IP overrides (checked first)
cat /etc/resolv.conf    # which resolver(s) to ask + search domains + ndots
cat /etc/nsswitch.conf  # the "hosts:" line sets files-vs-dns order

dig www.example.com            # full query + answer + TTL
dig +short www.example.com     # just the IP
dig +trace www.example.com     # walk root -> TLD -> authoritative yourself
nslookup www.example.com       # simpler lookup
getent hosts www.example.com   # resolve the way the OS (nsswitch) would

Every record carries a TTL. Resolvers cache answers for that long, so a DNS change can take up to the old TTL to propagate. Lower the TTL before a planned migration, then raise it again afterwards.

   record TTL = 300s  ->  resolvers may serve the OLD IP for up to 5 minutes
   plan a cutover: drop TTL to 60s a day early, migrate, then restore

A name is resolved by walking the resolver hierarchy, caching at each hop.

Graph legend — the full resolution of www.example.com, step by step:

• DNS resolves names by walking root -> TLD -> authoritative, caching at each hop.
• The recursive resolver does the walking; your OS stub just asks it.
• /etc/hosts (via nsswitch) usually wins before DNS is even queried.
• Records: A/AAAA (IP), CNAME (alias), NS/MX/TXT/PTR/SRV.
• TTL controls caching — lower it before planned cutovers.
• dig +trace and getent hosts are your debugging workhorses.

• [ ] Can describe the stub -> recursive -> root/TLD/authoritative chain
• [ ] Read /etc/resolv.conf and /etc/hosts on a host
• [ ] Used dig +short and dig +trace on a real domain
• [ ] Can explain TTL and why DNS changes appear delayed
• [ ] Know A vs CNAME vs SRV (SRV matters for Day 31)