Networking: Life of a Packet
25 min
Day 18: DNS: recursion, records, TTL
DNS: the internet's phone book
DNS translates human-readable names (example.com) into IP addresses. Your resolver typically doesn't know the answer itself — it asks a recursive resolver (often your ISP's, or a public one like 1.1.1.1), which does the actual work of walking the hierarchy on your behalf.
Recursive resolution, step by step
- Ask a root server: "who handles .com?" → get referred to the .com TLD servers
- Ask a .com TLD server: "who handles example.com?" → get referred to example.com's authoritative name servers
- Ask the authoritative name server: "what's the A record for example.com?" → get the actual IP
- Cache the answer for the record's TTL, so this whole walk isn't repeated on every request
Common record types
- A — hostname to IPv4 address
- AAAA — hostname to IPv6 address
- CNAME — alias pointing to another hostname
- MX — mail server responsible for the domain
- TXT — arbitrary text, often used for domain verification / SPF
TTL is a caching trade-off, not a technical detail
A low TTL (e.g. 60s) lets you change where traffic points quickly — useful during an incident or migration — but means every resolver re-asks far more often, adding load and latency. A high TTL is efficient but makes DNS-based failover slow to take effect. This exact trade-off shows up again with HTTP caching (Day 20).
Watching this yourself (from Day 12's dig)
dig example.com
# Look at the ANSWER SECTION and its TTL value
dig +trace example.com # shows the full recursive walk, root -> TLD -> authoritativeKey terms
- Recursive resolver
- A DNS server that performs the full lookup chain on behalf of a client.
- Authoritative name server
- The server holding the actual, official DNS records for a domain.
- TTL (Time To Live)
- How long a DNS answer may be cached before it must be re-queried.
During an incident, why might an engineer temporarily lower a DNS record's TTL?
