Free lesson · System Design Crash Course

DNS Resolution End-to-End

Easy10 min readsystem-designhlddistributed-systems

Lesson 4.1 - DNS Resolution End-to-End

The first networking lesson.

Let me set up the question this lesson answers. You type google.com in your browser and press Enter. The browser needs to send a request to Google's servers. But the network doesn't route by names like "google.com" - it routes by IP addresses like 142.250.80.46. Somehow, in the time it takes you to blink, the name has to become an IP address. How?

The answer is DNS - the Domain Name System. DNS is the phonebook of the internet. Names go in, IP addresses come out. It's been around since 1983, it's distributed across millions of servers globally, it's mostly invisible when working, and it occasionally goes wrong in ways that take down half the internet.

This lesson takes you through how DNS actually works. By the end, you'll know what happens during the ~50ms (or 1ms, cached) between "click" and "request sent." You'll also understand why DNS is one of those subtle infrastructure layers where small misconfigurations cause big problems.

The Basic Idea

Computers communicate by IP address. Humans remember names. DNS is the bridge.

When you type google.com, your computer needs to ask: "what's the IP address for google.com?" The answer comes back ("142.250.80.46"), and then the actual request can be sent.

If this lookup took a long time every time, the web would be unusable. So DNS is designed with caching at almost every layer - by the time most lookups happen, the answer is already cached somewhere close. The full "go ask the authoritative servers" path is rare; the "I have this cached" path is common.

Let me show you both paths.

The Hierarchy: Root → TLD → Authoritative

Here's the structure of DNS that you need to know.

DNS is a hierarchical, distributed system. Names are read right-to-left:

www.google.com. (The trailing dot is the implicit root.)

Reading right-to-left:

• . = the root
• .com = a TLD (top-level domain)
• google.com = an authoritative zone
• www.google.com = a specific hostname within that zone

Each level has its own servers, run by different parties:

• Root servers know which servers handle each TLD. There are 13 root server "letters" (A through M), each operated by a different organization. They are managed at the global level. Every DNS resolver knows where the root servers are.

• TLD servers (run by registries - Verisign runs .com, etc.) know which authoritative servers handle each domain within that TLD. Ask the .com TLD: "who handles google.com?" - it tells you Google's authoritative DNS servers.

• Authoritative servers (run by the domain owner, or their DNS provider like Route 53, Cloudflare, NS1) know the actual records: what IP www.google.com resolves to, what mail server handles @google.com email, etc.

Visually:

flowchart TD
    Root["Root Servers<br/>(13 letters, global)"]
    TLD["TLD Servers<br/>(.com, .net, .org, .io, etc.)"]
    Auth["Authoritative Servers<br/>(per-domain, e.g. ns1.google.com)"]

    Root -->|"who handles .com?"| TLD
    TLD -->|"who handles google.com?"| Auth
    Auth -->|"www.google.com → 142.250.80.46"| Result["Final IP"]

    style Root fill:#a78bfa,stroke:#8b5cf6,color:#000
    style TLD fill:#fbbf24,stroke:#f59e0b,color:#000
    style Auth fill:#34d399,stroke:#10b981,color:#000
    style Result fill:#fb7185,stroke:#f43f5e,color:#000

A diagram showing the DNS hierarchy. At the top, the root servers  - 13 different "letters" of them, operated by various organizations globally. They don't store every domain; they just know which TLD servers handle each top-level domain like .com or .org. Next level down, TLD servers, run by registries like Verisign for .com. They know which authoritative servers handle each domain within their TLD. At the bottom, authoritative servers  - the actual servers that know "www.google.com is at 142.250.80.46." A full DNS resolution traverses from root to TLD to authoritative, picking up the answer at each level. In practice, almost every step is cached, so a real lookup rarely traverses the whole chain.

This is the hierarchy. Now let's see how a query actually traverses it.

A Recursive Resolution, Step by Step

When you type www.google.com, the resolution happens in stages. Here's the cold-cache version - what happens when nothing is cached anywhere:

Step 1. Your browser asks the operating system: "what's the IP for www.google.com?"

Step 2. The OS asks its configured DNS resolver. This is usually your ISP's resolver, or a public resolver like Google's 8.8.8.8 or Cloudflare's 1.1.1.1. (Public resolvers have become popular for privacy and performance reasons.) Let's say the resolver is 8.8.8.8.

Step 3. The resolver has nothing cached, so it asks the root servers: "what handles .com?" The root servers respond: "TLD servers for .com are at these addresses."

Step 4. The resolver asks a .com TLD server: "who handles google.com?" The TLD server responds: "The authoritative servers for google.com are at these addresses (e.g., ns1.google.com)."

Step 5. The resolver asks Google's authoritative server: "what's the IP for www.google.com?" The authoritative server responds: "142.250.80.46."

Step 6. The resolver returns "142.250.80.46" to your OS, which returns it to your browser. The browser now has the IP and can open a connection.

sequenceDiagram
    participant B as Browser
    participant OS as Your OS
    participant R as DNS Resolver
    participant Root as Root Server
    participant TLD as .com TLD
    participant Auth as Google Auth Server

    B->>OS: Resolve www.google.com
    OS->>R: Recursive query
    R->>Root: Where is .com?
    Root-->>R: Ask TLD server
    R->>TLD: Where is google.com?
    TLD-->>R: Ask ns1.google.com
    R->>Auth: What is www.google.com?
    Auth-->>R: 142.250.80.46
    R-->>OS: 142.250.80.46
    OS-->>B: 142.250.80.46

A sequence diagram showing a cold-cache DNS resolution. The browser asks the operating system to resolve www.google.com. The OS asks the configured DNS resolver. The resolver has no cache, so it goes to the root servers and asks where .com is handled. The root tells it which TLD server handles .com. The resolver then asks that TLD server where google.com is handled. The TLD server returns the address of Google's authoritative DNS servers. The resolver then asks one of Google's auth servers for the actual IP of www.google.com. The auth server returns 142.250.80.46. That answer flows back through the resolver, the OS, and finally to the browser. In total, four round trips to four different servers. This is the cold-cache path.

This is the iterative part - the resolver does the iteration through the hierarchy on your behalf. From your perspective (the client), this is a single recursive query - you ask one question, you get one answer, and the work behind the scenes is hidden from you.

The cold-cache version takes maybe 50–200 ms total, depending on how far each server is.

Caching at Every Layer

In practice, almost nothing is cold. DNS caches aggressively at multiple layers:

1. Browser cache. Browsers cache DNS responses for a short time (minutes). When you visit Google multiple times in quick succession, the browser doesn't ask the OS again - it has the answer.

2. OS cache. Operating systems have their own DNS cache (nscd on Linux, the DNS Client service on Windows, mDNSResponder on Mac). This survives across applications.

3. Resolver cache. The DNS resolver (your ISP's or a public one) caches answers it got. This is the biggest cache - if anyone using 8.8.8.8 just looked up google.com, the answer is cached there for everyone.

4. TLD cache. The resolver also caches "the TLD servers for .com are at these addresses." This rarely changes, so it can be cached for a long time.

5. Root cache. Similarly, root server addresses are well-known and rarely change.

Result: a typical DNS lookup for a popular domain is essentially instant, often <1ms because everything is cached locally.

Each cached record has a TTL (Time To Live) that determines how long it stays cached. Common TTLs:

• TLD records: 24-48 hours (very stable)
• Authoritative records for most websites: 5 minutes to 24 hours
• Records during deployments: often set to 60-300 seconds for fast change propagation

Lower TTL = faster propagation of changes, but more DNS lookups (more load on authoritative servers). Higher TTL = fewer lookups but slower propagation. This is a real trade-off your team will face if you operate DNS records.

DNS Record Types

You should know the major DNS record types:

In day-to-day system design, you'll mostly encounter A/AAAA (for routing traffic), CNAME (for aliases), and TXT (for verification). The others matter in specific contexts.

A subtle thing about CNAME: it's an alias, so a CNAME lookup actually triggers a second lookup. www.example.com → example.com means: resolve www.example.com, get back "go look up example.com", then resolve example.com. This adds latency. There are also rules about where CNAMEs can be used (e.g., not at the root of a domain), which trip up engineers occasionally.

DNS as Load Balancing and Failover

DNS isn't just for name resolution - it's also a way to do load balancing and failover.

DNS round-robin: if you have multiple servers, you can return multiple A records for the same name. Clients pick one (typically randomly or in order). Each client ends up on a different server.

www.example.com → 1.2.3.4
www.example.com → 1.2.3.5
www.example.com → 1.2.3.6

This is a basic form of load balancing. It's cheap (no extra infrastructure) but limited - DNS doesn't know if a server is healthy, so traffic still routes to dead servers until the record is updated.

GeoDNS: more sophisticated. The DNS server returns different IPs depending on where the client is. A user in Asia gets an IP in Asia; a user in the US gets an IP in the US. This is how global services route to the nearest datacenter.

DNS failover: when a server dies, you update DNS to remove it. Clients with new lookups go to the remaining servers. Clients with cached records still hit the dead server until their cache expires - this is why lower TTLs matter for failover speed.

These patterns are how every large website handles routing at the global level. Looking up www.netflix.com from Tokyo returns a different IP than looking up the same name from London. The "single name, multiple IPs based on location" pattern is the foundation of how the internet scales.

DNS-Over-HTTPS and DNS-Over-TLS

A modern wrinkle. Traditional DNS is sent over UDP (port 53) unencrypted. Anyone in the network path can see your DNS queries. This is a privacy and security issue - it's how some ISPs serve ads or government censors block sites.

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt DNS queries. The browser or OS makes DNS queries over an encrypted channel to a resolver that supports DoH/DoT (like Cloudflare's 1.1.1.1 or Google's 8.8.8.8).

This has implications:

• Privacy improves - ISPs and other intermediaries can't see DNS queries
• Performance can improve - DoH can reuse existing HTTPS connections instead of opening a separate UDP path
• Network operators lose visibility - sometimes legitimate (security tools that monitor DNS), sometimes objectionable (censorship)

Most modern browsers and operating systems support DoH/DoT. It's becoming the default for new deployments.

When DNS Goes Wrong

DNS misconfigurations cause some of the most memorable outages:

1. DNS as a single point of failure. If your authoritative DNS provider goes down, your site becomes unreachable even if the servers are fine. Famous example: the 2016 Dyn DNS attack took down Twitter, Spotify, GitHub, Netflix, and others because they all used Dyn.

2. TTL too long. When you need to change DNS records (e.g., failing over to a backup datacenter), high TTLs mean slow propagation. If your TTL is 86,400 (24 hours), it can take a full day for users to see changes.

3. Forgetting redundant authoritative servers. Best practice is to use 2+ authoritative DNS providers. Many companies use only one; when it goes down, they go down.

4. Negative caching. If your DNS returns NXDOMAIN ("no such record"), that NXDOMAIN can be cached too. If you accidentally publish a bad record, the bad answer caches for the TTL.

5. DNSSEC mistakes. DNSSEC is cryptographic signing of DNS responses. Misconfigured DNSSEC can make domains unreachable. Many ops teams have been burned by this.

These are real risks, not theoretical. Major companies have lost millions of dollars to DNS misconfigurations. Treating DNS as critical infrastructure - with monitoring, redundancy, and careful change management - is essential.

How Long Does DNS Take?

Practical numbers:

• Browser cache hit: ~0 ms (instant)
• OS cache hit: ~1 ms
• Resolver cache hit: ~5–30 ms (depends on distance to resolver)
• Cold lookup, popular domain: ~20–50 ms (most layers cached)
• Truly cold lookup, all layers: ~100–300 ms

For a first-time visit to a new site, you might pay ~50 ms for DNS. For a repeat visit within minutes, it's essentially free.

This is why DNS prefetching is a real performance technique. Websites can hint to browsers: "you might soon need to look up subdomain.example.com, please prefetch it." The browser does the DNS lookup in the background, so by the time the user actually clicks, the IP is already known. This shaves visible latency from the user experience.

Six Takeaways from This Lesson

1. DNS is hierarchical: root → TLD → authoritative. Cold-cache resolution traverses this chain; cached resolution skips most of it.

2. Caching happens at multiple layers - browser, OS, resolver, intermediate. Most lookups are sub-millisecond because of caching.

3. TTL controls cache duration. Lower TTL = faster change propagation but more lookup volume. Higher TTL = better cache hits but slower changes.

4. DNS is also load balancing and failover. Multiple A records, GeoDNS, and DNS-based failover are foundational scaling techniques.

5. DNS is a single point of failure if you let it be. Use multiple authoritative providers and monitor your DNS infrastructure carefully.

6. Cold DNS adds ~50 ms; cached DNS is essentially free. For first-time visits, this is real latency to budget for.

Try It

Exercise: Warmup (10 minutes). On your terminal, run dig google.com and dig +trace google.com. Note the trace shows the resolution path through root, TLD, and authoritative servers.

Exercise: Core (20 minutes). Look up the DNS records for three popular sites (Netflix, Stripe, GitHub) using dig or an online DNS tool. Note their record types, TTLs, and authoritative servers. Are they using multiple DNS providers?

Exercise: Stretch (30 minutes). Read the postmortem of a real DNS-related outage (the Dyn 2016 attack, or any of Cloudflare's DNS incident postmortems). Note what went wrong, how it was detected, and how it was mitigated.

What's Next

Lesson 4.2 covers TCP - the transport protocol underneath most HTTP requests. We'll see the three-way handshake, slow start, and why TCP connections are more expensive than they look.

Back to System Design Crash Course