The Runtime Theory

DNS Resolution Flow: From Resolver to Root, TLD, and Authoritative Server

Trace a DNS lookup as the recursive resolver queries root, TLD, and authoritative servers, walks referrals, and caches answers with TTLs before the client connects.

The Runtime Theory Team07 stages

trace / request.md

APP CALLSGETADDRINFORESOLVERCACHE CHECKROOT SERVERREFERRALTLD SERVERREFERRALAUTHORITATIVEANSWERCACHING ATEVERY HOPANSWERRETURNS TO APP

readyThe application asks the OS to resolve api.example.com. The stub resolver builds a UDP query and sends it to the configured recursive resolver on port 53.

Every hostname lookup is a small distributed query against a hierarchy the machine walks mechanically. Your stub resolver only knows one address: the recursive resolver's. That recursor is the one that actually climbs the tree — root server for a .com referral, TLD server for the domain's nameservers, and finally the authoritative server that owns the zone.

The response path matters as much as the query path: each level caches the referral it obtained, so the recursion happens once and subsequent lookups are answered from cache until the TTL expires. Nothing is authoritative upstream of the zone's own servers — root and TLD servers only point, they never answer for api.example.com. That separation of pointing and answering is why adding a new TLD or moving a zone requires only a small change at one level, and why a cached answer can briefly outlive a record change at the source.