DNS resolution
“Walk through how `api.example.com` becomes an IP address, from the application call to the authoritative server. Who is involved and who caches what?”
What this tests
- The chain: stub resolver → recursive resolver → root → TLD → authoritative
- Where caching happens and what the TTL governs
- Which failures come from which participant
Answers by level
Read the beginner answer first and notice what is missing.
The application calls getaddrinfo() (or the runtime’s equivalent). The OS stub resolver checks /etc/hosts and its local cache (Linux: systemd-resolved if present, otherwise none; macOS: mDNSResponder; browsers keep their own short cache too), then sends a query to the configured recursive resolver from /etc/resolv.conf — the ISP’s, the corporate one, or a public one like 1.1.1.1. The stub does one thing: ask and wait.
The recursive resolver does the work. On a cache miss it asks a root server (whose addresses it has built in), which refers it to the .com TLD servers; they refer it to example.com’s authoritative nameservers (the NS records from the registrar delegation); those answer with the A/AAAA records for api.example.com. Each referral is cached, so the next lookup under .com skips the root, and the next lookup in example.com skips the TLD. The final answer is cached for the record’s TTL, which the zone owner sets. Queries are UDP/53 by default, retried over TCP when the answer is large or truncated; DNS-over-HTTPS/TLS encrypts the stub → resolver leg.
Every participant fails differently. NXDOMAIN is the authoritative server saying the name does not exist (and negative answers are cached too). SERVFAIL is the resolver saying it could not get an answer — authoritative servers down, DNSSEC validation failed, lame delegation. A timeout means the resolver itself is unreachable. And a stale answer is every cache doing its job correctly with an old TTL — the most common "DNS problem" is not a failure at all.
Green flags · Red flags
- Separates stub, recursive, root, TLD and authoritative — and says the recursive one does the work
- Knows caching happens at several layers and the TTL is set by the zone owner
- Distinguishes NXDOMAIN, SERVFAIL, timeout and stale answers
- Mentions A and AAAA as separate queries
- Names a real client-side pitfall: resolver timeouts, JVM caching, ndots
- Thinks the client walks the hierarchy itself
- Believes "flushing DNS" locally fixes a public resolver’s cache
- Cannot say what a TTL is for
- Confuses NXDOMAIN with "DNS server down"