diagram.mmd — sequence
How DNS Works sequence diagram

DNS (Domain Name System) is the distributed naming system that translates human-readable hostnames like example.com into the IP addresses computers use to route network traffic.

When you type a URL into your browser, a DNS resolution process begins before a single byte of HTTP traffic is exchanged. This diagram traces that process from the initial browser query through each layer of the DNS hierarchy.

The process starts with the browser checking its local DNS cache — a short-lived in-memory store keyed by hostname. If the entry exists and the TTL (Time to Live) hasn't expired, the IP is returned immediately, skipping the entire recursive lookup. This is why DNS caching matters so much for perceived performance; see DNS Caching Flow for a deeper look at the caching layers involved.

When there's a cache miss, the query is forwarded to a recursive resolver — typically provided by your ISP or a public resolver like 8.8.8.8. The resolver acts on the client's behalf, working up the DNS hierarchy. It first contacts a root name server, one of 13 logical server clusters that know only which TLD servers handle each top-level domain (.com, .org, .io, etc.).

The root server returns the address of the appropriate TLD name server. For example.com, that means the .com TLD servers operated by Verisign. The TLD server doesn't know the final IP — it knows which authoritative name server is responsible for the specific domain. The resolver queries that authoritative server and finally receives the actual A or AAAA record.

The resolver caches the result (respecting the record's TTL), forwards it to the local cache, and the browser gets the IP it needs to open a TCP connection. The full round-trip — hitting multiple geographically distributed servers — typically completes in 20–120ms for a cold lookup.

For developers, understanding this flow explains why DNS propagation delays occur after changing records (old TTLs must expire across resolvers), why low TTLs increase resolver load, and why DNS over HTTPS improves privacy by encrypting this query chain. DNS resolution also feeds directly into the HTTP Request Lifecycle and HTTPS Handshake that follow.

Free online editor
Edit this diagram in Graphlet
Fork, modify, and export to SVG or PNG. No sign-up required.
Open in Graphlet →

Frequently asked questions

DNS (Domain Name System) is the internet's distributed directory service that translates human-readable hostnames like `example.com` into IP addresses that routers use to deliver traffic. Without DNS, every application would need to hard-code IP addresses instead of domain names.
The browser first checks its local DNS cache. On a miss, it queries the OS stub resolver, which forwards to a recursive resolver (your ISP's or a public one like 8.8.8.8). The resolver queries a root name server, which refers it to the TLD name server, which refers it to the authoritative name server for the domain. The authoritative server returns the actual IP record, which is cached at each layer and returned to the browser.
A cold DNS lookup can take 20–120ms as the recursive resolver walks the DNS hierarchy. Subsequent lookups within the TTL window are served instantly from cache — at the browser, OS, or resolver level. High-traffic domains are almost always cached at the resolver level, making repeat lookups sub-millisecond.
Once the browser has the server's IP address, it proceeds to open a TCP connection (the three-way handshake), perform a TLS negotiation for HTTPS, and then send the HTTP request. DNS resolution is only the first phase of the full HTTP Request Lifecycle.
mermaid
sequenceDiagram participant Browser participant LocalCache as Local DNS Cache participant Resolver as Recursive Resolver participant Root as Root Name Server participant TLD as TLD Name Server participant Auth as Authoritative Name Server Browser->>LocalCache: Query: example.com? alt Cache hit LocalCache-->>Browser: Return cached IP (TTL valid) else Cache miss LocalCache->>Resolver: Forward query: example.com? Resolver->>Root: Who handles .com? Root-->>Resolver: TLD server: a.gtld-servers.net Resolver->>TLD: Who handles example.com? TLD-->>Resolver: Authoritative: ns1.example.com Resolver->>Auth: What is the IP for example.com? Auth-->>Resolver: A record: 93.184.216.34 (TTL 3600) Resolver-->>LocalCache: Cache result with TTL LocalCache-->>Browser: 93.184.216.34 end note">Note over Browser: Opens TCP connection to 93.184.216.34
Copied to clipboard