AlgoInsight

System Design

How DNS Actually Works

Every connection you make starts with a DNS lookup, yet most engineers treat it as magic. It isn't - it's an elegant, distributed lookup system. Here's exactly what happens between typing a domain name and reaching the server.

By Admin2026-06-1814 min readdnsnetworkingsystem-designinfrastructureinternetinterview

Every time you load a website, send an email, or call an API, the very first thing that happens - before any data is exchanged - is a DNS lookup. It's so fundamental and so fast that most engineers treat it as magic: you type example.com, and somehow you reach the right server. But there's no magic, just an elegant, globally distributed system doing a lookup in milliseconds. Understanding how DNS actually works demystifies a piece of infrastructure every system depends on, and it comes up regularly in system design.

This guide walks through exactly what happens between typing a domain name and reaching the server.

What DNS is and why it exists

DNS - the Domain Name System - translates human-friendly domain names into the IP addresses computers use to find each other. Computers route traffic using IP addresses (like 93.184.216.34), but humans can't remember strings of numbers for every site. DNS bridges that gap: it lets us use memorable names (example.com) while computers use the underlying numbers. The classic analogy is a phonebook - you look up a name to get the number.

So DNS solves a real problem: names are for humans, addresses are for machines, and something has to translate between them, at internet scale, for billions of lookups. What makes DNS remarkable is that it does this as a distributed, hierarchical system - no single server holds all the mappings (that wouldn't scale or survive), so the work is spread across a hierarchy of servers worldwide.

The cast of characters

DNS resolution involves several types of servers, each with a role:

The resolution process, step by step

Here's what happens when your device needs the IP for example.com and nothing is cached:

  1. Your device asks its resolver: "What's the IP for example.com?"
  2. The resolver asks a root nameserver. The root doesn't know example.com's IP, but it replies, "Ask the .com TLD servers - here's where they are."
  3. The resolver asks a .com TLD nameserver. It doesn't know the IP either, but it replies, "Ask example.com's authoritative servers - here's where they are."
  4. The resolver asks the authoritative nameserver for example.com. This one does know, and replies with the IP address.
  5. The resolver returns the IP to your device, which can now connect to the server.

This whole chain - resolver to root to TLD to authoritative - usually completes in milliseconds. It's a walk down a hierarchy, each level pointing the resolver one step closer, until the authoritative server gives the final answer.

sequenceDiagram
    participant D as Your device
    participant R as Resolver
    participant Root as Root nameserver
    participant TLD as .com TLD server
    participant Auth as Authoritative server
    D->>R: IP for example.com?
    R->>Root: IP for example.com?
    Root-->>R: Ask the .com TLD servers
    R->>TLD: IP for example.com?
    TLD-->>R: Ask example.com's authoritative servers
    R->>Auth: IP for example.com?
    Auth-->>R: It's 93.184.216.34
    R-->>D: It's 93.184.216.34

This sequence diagram shows DNS resolution. Your device asks its resolver for the IP of example.com. The resolver asks a root nameserver, which points it to the dot-com TLD servers. The resolver asks a dot-com TLD server, which points it to example.com's authoritative servers. The resolver asks the authoritative server, which returns the actual IP address. The resolver passes that IP back to your device, which can now connect. The whole chain typically completes in milliseconds.

Caching: why it's fast

If every lookup walked the whole hierarchy, DNS would be slower and the root servers would be overwhelmed. The reason it's fast is caching at every level. Once a resolver learns example.com's IP, it caches it - stores it temporarily - so the next request for the same domain is answered instantly from the cache, no hierarchy walk needed. Your device and browser cache too. So the full resolution above happens only on a cache miss; most lookups are served from a cache somewhere along the way.

How long something is cached is controlled by a TTL (time-to-live) - a value attached to each DNS record saying how long it may be cached before the resolver should look it up fresh. A short TTL means changes propagate quickly but more lookups hit the hierarchy; a long TTL means fewer lookups but changes take longer to take effect. This is why DNS changes (like pointing a domain to a new server) can take time to propagate - caches around the world hold the old value until their TTL expires.

DNS records: more than just addresses

DNS stores different types of records for a domain, not just one IP. The common ones:

So DNS is more than a name-to-IP map - it's a flexible directory holding various kinds of information about a domain, with the A/AAAA records doing the core address lookup and others handling mail, aliases, and configuration.

Recursive vs. iterative queries

A useful distinction in how resolution actually proceeds: recursive versus iterative queries. When your device asks its resolver, it makes a recursive query - essentially "give me the final answer; do whatever work is needed." The resolver takes on full responsibility for finding the answer.

The resolver then makes iterative queries to the hierarchy: it asks the root, which refers it onward (doesn't resolve fully, just points to the next server); it asks the TLD, which refers it further; it asks the authoritative server, which finally answers. Each is iterative - the server gives a referral ("ask over there") rather than the full answer, and the resolver iterates step by step down the hierarchy.

So the resolver does recursive work on your behalf by making a series of iterative queries up the chain. This is why the resolver exists: it shoulders the iterative legwork so your device makes one simple recursive request and gets one answer. It also explains why the root and TLD servers don't get overwhelmed - they don't resolve anything fully, they just hand out referrals quickly, leaving the actual resolution distributed across the many resolvers worldwide.

The layers of caching

DNS caching happens at several layers, not just the resolver, and knowing them helps when debugging:

This layered caching is why most lookups are nearly instant - the answer is usually cached somewhere close, often right on your device. It's also why DNS issues can be confusing to debug: a stale entry might be cached at any of these layers, so a change that's live at the authoritative server might still be served from an old cache on your machine until it expires. (Clearing a DNS cache is a common troubleshooting step for exactly this reason.)

DNS propagation and its quirks

Because of caching and TTLs, DNS changes don't take effect everywhere instantly - they propagate. When you change a domain's IP (say, moving to a new server), the authoritative record updates immediately, but resolvers and devices worldwide keep serving the old cached value until their TTL expires. So for a window of time (up to the TTL), some users reach the new server and some still reach the old one. This is "DNS propagation," and it's why you plan such changes carefully: lower the TTL before a planned change (so caches expire quickly), make the change, then raise the TTL again. Understanding propagation explains the common experience of "I updated DNS but it's not working for everyone yet" - the change is correct; the caches just haven't all expired.

What happens after DNS resolves

It's worth closing the loop: DNS resolution is just the first step. Once your device has the IP, DNS's job is done - and the actual connection begins. Your device opens a connection to that IP (a TCP connection, a TLS handshake for HTTPS), sends its HTTP request, and gets the response. DNS doesn't carry any of your actual data; it only tells your device where to send it. This is why DNS is the phonebook: it gives you the number, and then you make the call separately. Keeping this clear - DNS finds the address, then the real connection happens over TCP/HTTP - prevents the common confusion of thinking DNS serves the page. It doesn't; it just points the way.

DNS reliability and security

Because everything depends on DNS, two operational concerns matter:

Redundancy. DNS is a critical dependency - if your DNS fails, users can't reach your system even if the servers are perfectly healthy, because they can't resolve the name to an address. This is why domains specify multiple authoritative nameservers, why serious operations use redundant DNS providers, and why a DNS provider outage can take down large swaths of the internet. Treating DNS as a single point of failure to be made redundant is part of running reliable systems.

Security. DNS was designed in a more trusting era, so security has been added over time. Lookups can be tampered with (directing users to malicious servers), which is the problem DNSSEC (DNS Security Extensions) addresses by letting responses be cryptographically verified as authentic. Separately, because ordinary DNS queries are unencrypted, newer approaches encrypt them (DNS over HTTPS/TLS) for privacy. You don't need the deep details, but knowing that plain DNS is neither authenticated nor private by default is part of understanding it fully.

DNS in practice: what you'll actually do with it

For all its underlying complexity, DNS is something developers interact with through a few common, practical tasks - and knowing them grounds the theory:

These tasks are where DNS stops being abstract. Behind each one is the hierarchy and caching described above - but in daily practice, DNS is mostly "set the right records, and understand that changes take time to propagate." Knowing both the mechanism and the practical tasks is what lets you use DNS confidently rather than treating it as a mysterious place where domains sometimes break.

Why DNS matters in system design

DNS isn't just plumbing - it's a tool you use in system design:

Understanding DNS as a distributed, cached, hierarchical lookup - and as a routing tool - is part of reasoning about how systems are reached and distributed globally.

Interview: DNS appears in system design when discussing how users reach your system and how traffic is routed globally. Knowing the resolution flow (resolver → root → TLD → authoritative), that caching with TTLs makes it fast and makes changes propagate slowly, and that DNS can do geographic routing and load balancing (returning different IPs to direct users to the nearest or healthiest server) shows real infrastructure understanding. Mentioning DNS as the entry point for global traffic routing - and a critical dependency to make redundant - is a strong, senior-level detail.

The bottom line

DNS translates human-friendly domain names into the IP addresses computers use, through an elegant distributed hierarchy. A resolver does the legwork, walking from a root nameserver (which points to the right TLD) to a TLD nameserver (which points to the domain's authoritative servers) to the authoritative server (which gives the actual IP). Caching with TTLs makes this fast - most lookups hit a cache rather than walking the whole chain - and is also why DNS changes take time to propagate. Beyond name-to-IP, DNS stores various record types (A, AAAA, CNAME, MX, NS, TXT), and it doubles as a global traffic-routing tool through geographic and load-balancing responses.

Every connection starts here, so understanding DNS is understanding the first step of everything. We cover DNS and networking infrastructure across System Design Fundamentals.

Go deeper

More articles