DNS Resolution When You Type a URL

Walk me through what happens when you type a URL and press Enter, focusing specifically on the DNS resolution process.

junior

beginner

System Design

Question

Walk me through what happens when you type a URL and press Enter, focusing specifically on the DNS resolution process.

Answer

When you type 'example.com' and press Enter, the browser first checks its own DNS cache. If there is no cached result, it asks the operating system's stub resolver, which checks the OS-level cache (and on Linux, potentially systemd-resolved or nscd). If still unresolved, the query goes to your configured recursive resolver, usually provided by your ISP or a public resolver like 8.8.8.8 or 1.1.1.1. The recursive resolver checks its own cache, and if it has nothing, it starts the iterative resolution process: first it asks a root name server (one of 13 root server clusters, like a.root-servers.net) which responds with the TLD name servers for '.com'. Then it asks a '.com' TLD server, which responds with the authoritative name servers for 'example.com'. Finally, it asks the authoritative server, which returns the actual IP address (e.g., 93.184.216.34). The recursive resolver caches the answer according to the TTL and returns it to your machine. The entire process, when fully uncached, involves 4 network round-trips but typically completes in 20-120ms. Most queries hit a cache at some level and resolve in under 5ms.

Why This Matters

DNS is the entry point for virtually every internet interaction, yet many developers treat it as a black box. This question separates candidates who understand the layered architecture of the internet from those who just know 'DNS translates names to IPs.' It also opens the door to discussions about caching behavior, TTLs, security (DNS spoofing, DNSSEC), and how DNS-based load balancing and failover work. For a junior candidate, the interviewer wants to see awareness of the recursive vs. iterative resolution distinction and the caching hierarchy.

Code Examples

Tracing DNS resolution step by step

bash

Simulating the DNS resolution hierarchy

python

DNS resolution flow diagram

text

Common Mistakes

Describing DNS as a single lookup rather than a multi-step hierarchical process
Not mentioning caching at any level, which is what makes DNS fast in practice
Confusing the recursive resolver with the authoritative server
Forgetting that DNS uses UDP by default (port 53), not TCP, for standard queries
Skipping the root server step and jumping straight to the authoritative server
Not knowing that there are 13 root server clusters (not 13 individual machines)

Follow-up Questions

Interviewers often ask these as follow-up questions

What happens if the authoritative DNS server is down? How does redundancy work in DNS?
How does DNS-based load balancing work, and what are its limitations?
What is a TTL, and what are the tradeoffs of setting it very low vs. very high?
What is DNSSEC, and what problem does it solve?
How does DNS prefetching in browsers improve page load performance?