URL Parsing & DNS
Hostname → IP address
The browser parses the URL (RFC 3986), extracts the hostname, and resolves it to an IP address via the DNS hierarchy — cache → stub resolver → recursive resolver → authoritative nameserver.
How It Works
When your code calls fetch('https://api.example.com/data'), the browser first parses the URL according to RFC 3986. It extracts the scheme (https), host (api.example.com), port (443, implied by https), path (/data), and any query string or fragment. The hostname must be resolved to an IP address before a connection can open.
DNS resolution is a hierarchical lookup. The browser checks its own cache first (~1000 entries, 60-second default TTL). If the entry isn't cached, the OS stub resolver checks its cache and forwards to the configured recursive resolver (your ISP's, or a public one like 1.1.1.1 or 8.8.8.8). The recursive resolver walks the DNS tree: root nameservers → .com TLD nameservers → example.com's authoritative nameservers, which return the final A (IPv4) or AAAA (IPv6) record. Each step is cached with a TTL, so most lookups resolve from cache in under 1 ms.
The Signal Flow
Key Concepts
The universal syntax for identifying resources: scheme://authority/path?query#fragment. Every URL you've ever used follows this grammar. The spec defines percent-encoding for special characters.
DNS is a distributed tree database. The root zone knows TLDs (.com, .org), TLDs know second-level domains (example.com), and authoritative servers know the actual IP addresses. ~13 root server anycast groups serve the entire internet.
Each DNS record has a TTL in seconds — how long resolvers should cache it. Short TTLs (60s) allow fast updates; long TTLs (86400s) reduce lookup latency. The DNS propagation delay you've heard of is just TTL expiration.
Traditional DNS queries are unencrypted UDP — anyone on the network can see which domains you look up. DoH (RFC 8484) wraps DNS queries in HTTPS, encrypting them from your browser to the resolver.
Deep Dive
How recursive resolution works
When a recursive resolver has a cache miss, it starts at the root. It asks a root server 'where is api.example.com?' — the root says 'I don't know, but here are the .com TLD servers.' The resolver asks a .com server, which says 'here are example.com's nameservers.' Finally, example.com's authoritative server returns the actual A record. Each answer is cached with its TTL. A cold resolution might take 4 round trips (50–200 ms), but cached lookups return in under 1 ms.
Happy Eyeballs (RFC 8305)
Modern hosts often have both IPv4 (A record) and IPv6 (AAAA record) addresses. The Happy Eyeballs algorithm resolves both in parallel and races connection attempts — whichever IP version connects first wins. This ensures users get the fastest path without waiting for a timeout on a non-functional address family. Browsers implement this transparently.
Related Specs
Must-know specifications from the Naming & Addressing layer.
DNS is the phone book of the internet. Every domain, email MX record, SPF/DKIM TXT record, and service discovery entry depends on it.
The record types (A, MX, TXT, CNAME) you configure in every DNS panel live in this spec. Know what you're setting.
Every URL in your app, API, auth redirect, webhook, or deep link is built on this grammar. Essential for routing, redirects, and OAuth callback validation.
Browsers parse URLs per this standard, not raw RFC 3986. Critical for client-side routing, form encoding, and cross-origin behavior.