Typing www.example.com into a browser triggers a chain of DNS queries before any connection is made. This UML sequence diagram follows one lookup from the laptop's stub resolver through a recursive resolver to the root, the .com TLD and the authoritative server, then shows how caching changes the picture.
1. The Diagram
Stub query. The operating system's stub resolver asks its configured recursive resolver for the A record, with Recursion Desired set. The stub does no chasing itself.
Root. With an empty cache the recursive resolver starts at a root server (it ships with their addresses as root hints). The root does not know the answer; it returns a referral to the .com name servers plus their addresses (glue).
TLD. The .com server returns another referral: the NS records for example.com.
Authoritative.ns1.example.com owns the zone and returns the answer with the Authoritative Answer flag and a TTL of 300 seconds.
Cache and reply. The recursive resolver caches every record it learned for its TTL, then answers the stub. Total: four round trips on a cold cache, often 50 to 200 ms.
2. How to Read It
Solid arrows are queries, dashed arrows are responses. The yellow arrow is the only recursive query; the blue fragment groups the iterative queries in which each server only points to the next one.
A frequent misunderstanding is that the laptop talks to the root servers itself. It never does: the stub resolver asks one recursive resolver and waits, and only the recursive resolver walks the hierarchy. Tools such as dig +trace imitate that walk from your own machine.
3. Variant: Warm Cache and NXDOMAIN
Within the 300-second TTL the same question is answered from cache with no upstream traffic, and the remaining TTL counts down. A misspelt name still benefits from caching: the resolver already knows the .com servers, so it skips the root. The TLD replies NXDOMAIN with the zone's SOA record, whose minimum field tells the resolver how long to cache the negative answer.
4. Pros, Cons, and When to Use
Pros
Separates recursive and iterative queries, the most common point of confusion.
Makes cache behaviour and TTLs concrete.
Shows why a cold lookup is slow and a warm one is instant.
Easy to compare with dig +trace output.
Scales to extras such as CNAME chains or DNSSEC validation.
Cons
Five lifelines are wide; long labels must be abbreviated.
Hides retries, UDP truncation and TCP fallback.
Anycast and multiple name servers per level are reduced to one box.
Real resolvers do QNAME minimisation and prefetching, which a simple diagram omits.
When to use
Debugging slow or failing lookups, or stale records after a migration.
Planning TTLs before a cut-over.
Explaining split-horizon or private DNS zones.
When not to use
Showing which records exist in a zone (use a table).
Network placement of resolvers (use a topology diagram).
5. As Diagrams-as-Code
Mermaid sequenceDiagram:
sequenceDiagram
participant Stub as Stub resolver
participant Rec as Recursive resolver
participant Root as Root server
participant TLD as .com TLD
participant Auth as ns1.example.com
Stub->>Rec: A? www.example.com (RD=1)
Rec->>Root: A? www.example.com
Root-->>Rec: referral com. NS + glue
Rec->>TLD: A? www.example.com
TLD-->>Rec: referral example.com NS
Rec->>Auth: A? www.example.com
Auth-->>Rec: A 93.184.215.14 TTL 300 (AA)
Note over Rec: cache records for TTL
Rec-->>Stub: A 93.184.215.14