How DNS Works

Every time you type a URL into your browser, a behind-the-scenes process translates that human-readable domain name into an IP address your computer can actually connect to. That process is DNS — the Domain Name System.

The Problem DNS Solves

Computers communicate using IP addresses like 93.184.216.34. Humans prefer names like example.com. DNS bridges that gap. It's essentially a distributed phone book for the internet.

But it's not a single phone book sitting on one server. DNS is a hierarchical, distributed system spanning millions of servers worldwide. Understanding how queries flow through this hierarchy is key to understanding modern networking.

The Resolution Process

Here's what happens when you type example.com into your browser:

Let's walk through each step in detail.

Step 1: Browser Cache

Your browser first checks its own cache. If you visited example.com recently, the IP address might still be stored locally. If found, the browser skips the entire DNS lookup. Chrome, for example, caches DNS entries for up to 60 seconds.

Step 2: Operating System Cache

If the browser cache misses, the OS checks its own DNS cache. On macOS, you can inspect this with sudo dscacheutil -flushcache. On Linux, systemd-resolved maintains the cache. Most operating systems also check the /etc/hosts file at this stage.

Step 3: Recursive Resolver

If neither local cache has the answer, your computer sends a query to a recursive resolver — usually operated by your ISP, or a public resolver like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare). This resolver does the heavy lifting.

The resolver checks its own cache first. If it recently resolved example.com for another user, it returns the cached result immediately. This is why DNS propagation isn't instant — cached entries stick around until their TTL (Time to Live) expires.

Step 4: Root Name Server

If the recursive resolver doesn't have the answer cached, it starts at the top of the DNS hierarchy: the root name servers. There are 13 root server clusters (labeled A through M), operated by organizations like ICANN, Verisign, and NASA.

The root server doesn't know the IP of example.com. But it knows which servers are authoritative for the .com top-level domain. It responds with a referral to the .com TLD servers.

Step 5: TLD Name Server

The recursive resolver now queries a .com TLD name server. This server doesn't know the final IP either, but it knows which name servers are authoritative for example.com. It responds with those name server addresses.

Step 6: Authoritative Name Server

Finally, the recursive resolver queries the authoritative name server for example.com. This server has the definitive answer: the A record pointing example.com to 93.184.216.34.

The resolver caches this result (respecting the TTL), and returns it to your browser. Your browser opens a TCP connection to that IP address, and the page loads.

DNS Record Types

DNS doesn't just map names to IP addresses. Several record types serve different purposes:

• A Record — Maps a domain to an IPv4 address
• AAAA Record — Maps a domain to an IPv6 address
• CNAME — Creates an alias from one domain to another
• MX Record — Specifies mail servers for a domain
• TXT Record — Stores arbitrary text, often used for verification and SPF/DKIM
• NS Record — Delegates a domain to specific name servers

Why DNS Matters for System Design

DNS isn't just a networking concept — it's a critical piece of system architecture:

• Load balancing: DNS can distribute traffic across multiple IPs using round-robin or weighted records
• Failover: Health-checked DNS services (Route 53, Cloudflare) can route around failures
• CDNs: Content delivery networks use DNS to direct users to the nearest edge server
• TTL management: Low TTLs enable fast failover but increase DNS query load; high TTLs reduce load but slow propagation

Understanding DNS deeply helps you debug production issues, design resilient architectures, and reason about latency in distributed systems.