Metis

Field note / fundamentals

publishedupdated 2026-05-01#dns#networking#browser#http#interview

DNS + What Happens When You Type a URL

Full journey from URL to rendered page — DNS resolution, TCP, TLS, HTTP, browser rendering — with every step explained for interviews.

Overview

"What happens when you type google.com in a browser?" is one of the most common senior engineering interview questions. It tests breadth across networking, security, and web fundamentals. A strong answer covers 8+ distinct steps.

Architecture

FULL JOURNEY: "https://google.com" → rendered page
════════════════════════════════════════════════════════

STEP 1: Check caches (< 1ms)
────────────────────────────
  Browser → Chrome cache (visited this URL recently?)
  Browser → OS DNS cache (/etc/hosts, systemd-resolved)
  Browser → Router cache (ISP DNS cache)

STEP 2: DNS Resolution (10–100ms if cache miss)
────────────────────────────────────────────────
                    ┌─────────────┐
  Browser ─────────▶│ Recursive   │ (your ISP's / 8.8.8.8)
                    │ Resolver    │
                    └──────┬──────┘
                           │ cache miss
                           ▼
                    ┌─────────────┐
                    │ Root Name   │  "." → knows TLD servers
                    │ Server      │  returns: .com NS = a.gtld-servers.net
                    └──────┬──────┘
                           │
                           ▼
                    ┌─────────────┐
                    │ TLD Name    │  ".com" → knows google.com NS
                    │ Server      │  returns: ns1.google.com
                    └──────┬──────┘
                           │
                           ▼
                    ┌─────────────┐
                    │ Authoritative│  "google.com" → returns A record
                    │ Name Server │  142.250.80.46
                    └─────────────┘
                           │
                    Recursive resolver caches result (TTL: 300s)
                    Returns IP to browser

STEP 3: TCP Connection (1-RTT = ~20ms for nearby server)
─────────────────────────────────────────────────────────
  Client                        Server (142.250.80.46:443)
    │── SYN ──────────────────────▶│
    │◀─ SYN-ACK ──────────────────│
    │── ACK ──────────────────────▶│

STEP 4: TLS Handshake (1-RTT with TLS 1.3, ~20ms)
───────────────────────────────────────────────────
  Client hello → Server hello + cert → derive session key
  (see https-tls article for detail)

STEP 5: HTTP Request
──────────────────────
  GET / HTTP/2
  Host: google.com
  Accept: text/html
  Cookie: ...

STEP 6: Server Processing
──────────────────────────
  Load balancer → application server → cache check
  → database (if needed) → render/serialize response

STEP 7: HTTP Response
──────────────────────
  HTTP/2 200 OK
  Content-Type: text/html; charset=utf-8
  Cache-Control: no-cache
  Set-Cookie: ...
  <html>...</html>

STEP 8: Browser Rendering
───────────────────────────
  Parse HTML → build DOM tree
  Parse CSS → build CSSOM
  Combine → Render Tree
  Layout (reflow) → Paint → Composite
  Execute JavaScript → may trigger re-render
  Load sub-resources (img, css, js) → more requests from Step 3

Technical Implementation

DNS Record Types

A record     google.com      → 142.250.80.46     (IPv4)
AAAA record  google.com      → 2607:f8b0:...     (IPv6)
CNAME record www.google.com  → google.com         (alias)
MX record    google.com      → smtp.google.com    (mail)
TXT record   google.com      → "v=spf1 ..."       (SPF, DKIM, verification)
NS record    google.com      → ns1.google.com     (name server)
SOA record   google.com      → (zone metadata)

TTL (Time To Live) — how long resolvers cache the record
  Low TTL  (60s)  → fast propagation on changes, more DNS queries
  High TTL (86400s) → fewer queries, slow to update IP

DNS Lookup in Code

import dns from 'dns/promises';

// Lookup A record
const { address } = await dns.lookup('google.com', { family: 4 });
console.log(address);  // 142.250.80.46

// Full resolution with all record types
const records = await dns.resolve('google.com', 'MX');

// Reverse DNS (IP → hostname)
const hostname = await dns.reverse('8.8.8.8');
// [ 'dns.google' ]

TCP Three-Way Handshake

SYN  → Client says "I want to connect, my seq# = X"
SYN-ACK → Server says "OK, my seq# = Y, I acknowledge X+1"
ACK  → Client says "I acknowledge Y+1"

Cost: 1 full round-trip before ANY data is sent.
This is why HTTP/2 (persistent connections) and
QUIC (0-RTT resumption) matter — they amortize this cost.

Browser Rendering Pipeline

HTML  ──parse──▶  DOM
CSS   ──parse──▶  CSSOM
              ▼
         Render Tree
              ▼
           Layout    ← "reflow" — compute positions/sizes
              ▼
            Paint    ← draw pixels
              ▼
         Composite   ← GPU compositing of layers

Interview Preparation

Q: Walk me through what happens when you type "https://google.com" in a browser.

  1. Cache check: browser, OS, router DNS caches checked first.
  2. DNS resolution: if no cache, browser queries recursive resolver → root → TLD → authoritative name server → returns IP.
  3. TCP handshake: 3-way SYN/SYN-ACK/ACK to establish connection to port 443.
  4. TLS handshake: ClientHello, ServerHello, certificate validation, session key derivation (~1 RTT for TLS 1.3).
  5. HTTP request: GET / HTTP/2 with headers, cookies.
  6. Server processes: load balancer routes, app server handles, may query cache/DB.
  7. HTTP response: HTML with status 200.
  8. Browser renders: parse HTML → DOM, parse CSS → CSSOM, Render Tree → Layout → Paint → Composite. Sub-resources trigger additional requests.

Q: What is DNS TTL and when would you set it low vs high?

TTL (Time To Live) = how long DNS resolvers cache the record. Set TTL low (60–300s) before a planned IP migration — so the change propagates quickly. Set TTL high (3600–86400s) in steady state — fewer DNS queries, better performance. Rule of thumb: lower TTL 24 hours before you expect to change an IP.

Q: What is the difference between CNAME and A record?

A record maps hostname → IP address directly. CNAME maps hostname → another hostname (alias), which is then resolved to an IP. CNAMEs are useful for pointing www.example.com → example.com or pointing to a CDN's domain. You cannot use a CNAME on the zone apex (example.com itself, no www) — use ANAME/ALIAS records there.

Q: Why does DNS use UDP?

DNS queries/responses are small (< 512 bytes typically) and latency-sensitive. UDP has no handshake overhead — send the query, get the response. If no response arrives, the client retries. For large responses (DNSSEC, zone transfers), DNS falls back to TCP.

Learning Resources