DNS — Resolution, Caching & Records

DNS is the lookup layer that turns every hostname your service depends on into an IP address, and it sits on the critical path of every cold request. Interviewers probe it to see whether you understand caching layers, TTL trade-offs, and where a naming failure can take down an otherwise healthy system. DNS translates something a human can remember — api.example.com — into something a network can route to, like 203.0.113.10. That single translation step touches almost every layer above it: pick the wrong TTL and you either can't fail over fast enough during an incident, or you hammer your authoritative infrastructure with query volume you didn't plan for.

What Is DNS?

DNS (the Domain Name System) is essentially the internet's phone book: it converts a name a person can remember, like google.com, into the numeric address a computer needs to actually connect to it. Three ideas sit inside that one job:

• Resolution — the step-by-step process of asking around the internet's directory system until you get the right numeric address back.
• Caching — remembering an answer for a while after you get it, so the next request for the same name is instant instead of repeating the full lookup.
• Records — the actual entries stored in the directory (which name maps to which address, or to which other name), each with rules about what it's allowed to contain.

Where This Is Used

• Every single time you type a website address into your browser or open an app that talks to the internet.
• Companies like Cloudflare and Google run public DNS resolvers (1.1.1.1, 8.8.8.8) that millions of devices query directly.
• During a big product launch, engineering teams lower DNS TTLs in advance so they can redirect traffic quickly if something goes wrong.
• Outages at DNS providers (like the widely reported 2021 incidents) have taken down large chunks of the internet at once, since so many unrelated services depend on the same lookup layer.

A Day-to-Day Example

Think of an old-fashioned phone directory service. You call and ask for "Joe's Pizza," and the operator looks up the actual phone number and reads it back to you — you never needed to know the number yourself. If you call again five minutes later, you might just remember the number from last time instead of calling the operator again — that's caching. And the directory itself is organized into different kinds of listings (residential, business, forwarding numbers that ring somewhere else) — that's what different record types are for.

Deep Dive: The Full Resolution Path

A "cold" lookup — nothing cached anywhere — walks the DNS hierarchy from the top down. In practice this full walk is rare because of caching, but you need to know what it looks like when the cache is empty, because that's exactly the scenario interviewers draw on a whiteboard.

Client                Recursive Resolver         Root (.)        TLD (.com)      Authoritative (example.com)
  |  "api.example.com A?"    |                       |               |                   |
  |------------------------->|                       |               |                   |
  |                           |--"api.example.com A?"->|               |                   |
  |                           |<--"ask .com TLD"------|               |                   |
  |                           |----"api.example.com A?"------------->|                   |
  |                           |<--"ask example.com NS"---------------|                   |
  |                           |----"api.example.com A?"--------------------------------->|
  |                           |<--"A 203.0.113.10, TTL 300"----------------------------|
  |<--"203.0.113.10"---------|                       |               |                   |

Each referral step (root → TLD → authoritative) is called an iterative query — the root server doesn't know the answer, it only knows who to ask next. The client only ever makes one recursive query to its resolver and waits for a fully resolved answer; the resolver absorbs all the iterative hops. This is the recursive-vs-iterative distinction interviewers ask about directly: recursive = "give me the final answer, I don't care how," iterative = "tell me who to ask next."

Deep Dive: Record Types You'll Actually Use

• A — hostname → IPv4 address. api.example.com. 300 IN A 203.0.113.10
• AAAA — hostname → IPv6 address, same idea as A but 128-bit.
• CNAME — alias to another hostname, e.g. pointing www.example.com at a CDN-provided hostname like d111111abcdef8.cloudfront.net. A CNAME cannot coexist with other records on the same name (you can't have a CNAME and an MX on the same label).
• MX — mail routing, with a priority: example.com. 3600 IN MX 10 mail.example.com. Lower priority number wins first.
• NS — delegates a zone to a nameserver; this is literally how the TLD server tells the resolver "ask this authoritative server for example.com."
• TXT — arbitrary text, used heavily for domain verification and email anti-spoofing policy: SPF (v=spf1 include:_spf.google.com ~all) declares which servers may send mail for the domain, DKIM publishes a public key used to verify signed outgoing mail, DMARC tells receivers what to do when SPF/DKIM fail.

Key Pointers

• Resolution path: browser cache → OS resolver cache → recursive resolver (ISP or public, e.g. 8.8.8.8) → root server → TLD server → authoritative nameserver.
• The recursive resolver does the iterative walk on the client's behalf so the client only ever makes one query and waits for a final answer.
• TTL on each record controls how long it's cached at every layer — low TTL means fast propagation/failover but higher query load on authoritative servers; high TTL is cheap but slow to update.
• "DNS propagation delay" isn't really propagation — nothing pushes updates outward. It's every independent cache (browser, OS, ISP resolver, other resolvers worldwide) individually holding a stale record until its own TTL expires, which is why a change can take anywhere from seconds to the old record's full TTL to be visible everywhere.
• DNS defaults to UDP port 53 for small responses and falls back to TCP for larger payloads (zone transfers, DNSSEC, responses that exceed a single UDP packet, ~512 bytes classically or larger with EDNS0).

How It Works

1. The browser checks its own in-memory cache for a matching, unexpired record.
2. On a miss, the OS-level stub resolver is checked, then the query is forwarded to the configured recursive resolver.
3. The recursive resolver checks its own cache; on a miss it queries a root server, which returns a referral to the correct TLD server.
4. The resolver queries the TLD server and gets a referral to the domain's authoritative nameserver.
5. The resolver queries the authoritative server for the actual record, caches it per its TTL, and returns it to the client.
6. The client opens a TCP (or QUIC) connection, then TLS handshake, to the resolved IP.

Try It Yourself

# Walk the full hierarchy yourself, root down to authoritative — mirrors the diagram above
dig +trace example.com

# Query a single record type directly against the default resolver
dig example.com A
dig example.com MX
dig example.com TXT

# Ask a specific resolver directly (bypass your OS/ISP resolver's cache)
dig @8.8.8.8 example.com A

# Check the TTL that's actually cached right now (the "answer" section shows remaining TTL)
dig example.com A +noall +answer

# See the whole chain including CNAME resolution
dig www.example.com +trace

Interview Q&A

Q: What's the difference between a recursive resolver and an authoritative nameserver?

A: The recursive resolver is a middleman that does the work of walking the hierarchy on the client's behalf and caches the result; it doesn't own any zone data. The authoritative nameserver is the actual source of truth for a zone — it's the server that holds the real records for example.com and gives a definitive answer, not a cached copy.

Q: What is TTL and why does it matter operationally?

A: TTL is a per-record value telling every cache how long it may serve that record before re-querying. It's a direct lever on the freshness-vs-load trade-off: during a planned migration you'd lower TTL in advance so the cutover propagates fast; during steady state you keep TTL high to minimize load on authoritative infrastructure and reduce lookup latency for clients.

Q: What's the difference between an A record and a CNAME?

A: An A record maps a name directly to an IPv4 address. A CNAME maps a name to another name, which then gets resolved itself — it's an alias, not a final answer. You can't put a CNAME at the zone apex (e.g. bare example.com) alongside other required records like NS/SOA, which is why root-domain-to-CDN setups often use provider-specific "ALIAS" or "ANAME" records instead.

Q: What actually happens when a DNS cache entry expires?

A: The next lookup for that name is treated as a miss at that cache layer — it doesn't proactively refresh, it waits to be asked. That resolver then re-queries up the chain (or straight to authoritative, if it remembers the delegation) and re-caches the fresh answer for a new TTL window.

Q: Why can a DNS change take a while to be visible to everyone, even after you update the record immediately?

A: Because there's no push mechanism — every resolver and browser that already cached the old value keeps serving it until its own TTL expires, independently. If the old record had a 24-hour TTL, some fraction of the world can keep seeing the old answer for up to 24 hours after your change, even though the authoritative server already has the new one.

System Design Tie-in

DNS shows up constantly in system design interviews as the first step of "how does a request even reach your system" — and as a lever for global traffic steering. Geo-DNS and weighted/latency-based routing (e.g. Route 53 routing policies) let you send users to the nearest or healthiest region purely by returning different A records per resolver location, which is cheap but coarse: it decides where a client connects at DNS-lookup time and can't react to per-request backend health the way a real load balancer can. For blue-green deployments or disaster recovery, you'd deliberately lower TTL well before a planned cutover so the failover is visible everywhere quickly. DNS is also a classic single point of failure to call out — always assume interviewers want to hear "redundant, geographically distributed authoritative nameservers, ideally from more than one provider" when you're asked to make a system resilient.

Trade-offs

DNS caching trades freshness for speed and load: aggressive TTLs speed up failover during an incident but multiply query volume across every resolver in the path if lowered reactively without prior planning. DNS itself is a common single point of failure — always run redundant, geographically distributed authoritative nameservers. A frequent interview mix-up is conflating DNS-based load balancing (round-robin or geo-DNS answers) with true L4/L7 load balancing — DNS can only steer a client to a target at connection time, it can't react to per-request backend health the way a load balancer can.