DNS — Turning Names into Addresses

Routing operates on addresses, but humans (and most configuration) work with names — example.com, not 93.184.216.34. DNS (the Domain Name System) is the distributed, cached lookup that bridges the two, and it does it without any single server knowing every name on the internet.

TL;DR — in 30 seconds:

• An uncached name resolves through a chain — recursive resolver → root → TLD → authoritative server — but once any resolver in the chain has a cached answer, the rest of the walk is skipped.
• Every answer is cached at every hop for its TTL: shorter TTL means faster propagation but more lookups; longer TTL means fewer lookups but slower propagation when a record changes.
• Different record types answer different questions — A/AAAA hold an address, CNAME is an alias that still has to be resolved, MX names the mail server, NS names who's authoritative.

1. The resolution chain

A name that isn't cached anywhere gets resolved by walking a chain of increasingly specific servers:

sequenceDiagram
    participant C as Client
    participant R as Recursive resolver
    participant Root as Root server
    participant TLD as TLD server (.com)
    participant Auth as Authoritative server (example.com)
    C->>R: Resolve example.com?
    R->>Root: Who handles .com?
    Root-->>R: Ask the .com TLD servers
    R->>TLD: Who handles example.com?
    TLD-->>R: Ask example.com's authoritative servers
    R->>Auth: What's the A record for example.com?
    Auth-->>R: 93.184.216.34
    R-->>C: 93.184.216.34

• The recursive resolver (often your ISP's, or a public one) does the walking on the client's behalf and is the only server the client ever talks to directly.
• A root server doesn't know the final answer — it only knows which TLD (top-level domain, e.g. .com, .org) servers to ask next.
• A TLD server doesn't know the final answer either — it knows which authoritative server owns that specific domain.
• The authoritative server for example.com is the one place that actually holds the real answer.

2. Caching and TTL

Every answer in that chain is cached, at every level, for a duration set by its TTL (time to live). A short TTL means changes propagate fast but the chain gets walked more often; a long TTL means fewer lookups but slower propagation when a record changes. In practice, most of the chain above is skipped entirely once a resolver already has a cached answer — the full walk only happens for names nobody nearby has asked for recently.

3. Record types

DNS doesn't just map a name to an address — different record types answer different questions about a name:

Record	Answers
A	this name → an IPv4 address
AAAA	this name → an IPv6 address
CNAME	this name is an alias for another name (follow it, then resolve that)
MX	which mail server handles email for this domain
TXT	free-form text — commonly used for domain ownership verification and email anti-spoofing (SPF/DKIM)
NS	which servers are authoritative for this domain

4. How this connects

• Containers need name resolution too, just at a smaller scope: Kubernetes runs its own internal DNS (CoreDNS) so a Service name resolves to a ClusterIP the same way example.com resolves to a public address — covered in Kubernetes' Networking page (module 04, Kubernetes & Helm, §4 "Cluster DNS").
• Next: HTTP, TCP & SSH — what happens once a name has resolved to an address and a connection needs to actually open.

Common gotchas

• Assuming every lookup walks the full root→TLD→authoritative chain. Fix: that full walk only happens for a name nobody nearby has asked for recently — once any resolver in the chain has a cached answer, the rest of the walk is skipped entirely.
• Treating a CNAME as if it already holds the address. Fix: a CNAME is an alias — it points to another name that itself still has to be resolved (possibly through another CNAME) before an A/AAAA record actually hands back an address.
• Expecting a DNS record change to take effect everywhere the instant you make it. Fix: TTL is honored independently by every cache along the chain — resolvers, OSes, and browsers that already cached the old answer keep serving it until their own TTL expires, not the moment the record changes.
• Mixing up what different record types answer (e.g. expecting an NS record to name a mail server, or an MX record to hold an IP). Fix: each type answers one specific question — NS says who's authoritative, MX says which mail server, A/AAAA says the address itself.

Check yourself — you update a record's value, but some clients still resolve the old answer for a while. Why, and what determines how long?

Because the old answer is still sitting in a cache somewhere in the chain (resolver, OS, or browser) that hasn't expired it yet. Each cache independently honors the record's TTL — it keeps serving the cached value until its own TTL for that entry runs out, regardless of when the authoritative record actually changed.

Check yourself — a name has a CNAME pointing at another name. What has to happen before a client gets a usable IP address?

The alias has to be followed: the resolver takes the CNAME's target name and resolves that (following further CNAMEs if there are any) until it reaches an actual A or AAAA record. The CNAME itself never holds an address.

You can defend this when you can walk the full resolution chain for an uncached name without skipping a server, explain what a CNAME actually does (versus an A record), and say why a short TTL trades propagation speed for lookup volume.