DNS Resolution Process

The DNS resolution process converts a domain name into an IP address by walking a distributed, hierarchical tree of name servers. A client's stub resolver asks a recursive resolver to do the work; the recursive resolver then walks the hierarchy — root, top-level domain (TLD), authoritative — on the client's behalf, caching results along the way to avoid repeating that walk on every request.

1. Recursive and iterative DNS queries

There are two query styles involved in a single resolution, used by different parties in the chain.

• Recursive query: the stub resolver asks the recursive resolver for the complete answer. The recursive resolver takes on the responsibility of contacting other servers itself and returns only the final answer (or an error) — never a referral — to the client that asked.

• Iterative query: the recursive resolver asks each server in the hierarchy (root, then TLD, then authoritative) for the best answer it currently has. A server that doesn't hold the full answer responds with a referral — the address of a more specific server to ask next — rather than doing the extra work itself. The resolver follows each referral until it reaches an authoritative answer.

In short: the stub resolver only ever issues one recursive query; the recursive resolver issues a chain of iterative queries against the hierarchy to satisfy it.

2. A worked trace: resolving www.example.com on a cold cache

The table below is a real, verifiable trace — every IP and name server can be checked with dig against the live public DNS hierarchy.

Note on currency: for roughly two decades, example.com resolved to a single Verisign/Edgecast-hosted address, 93.184.216.34, with a 24-hour TTL. IANA re-platformed the reserved example domains in 2024; as of this writing they are served from Cloudflare's anycast network under different IPs and a much shorter TTL (a few hundred seconds instead of a day). The lesson generalizes beyond this one domain: DNS answers, name server assignments, and even TTL policy for a zone can all change over time, so a resolution trace is only as trustworthy as the freshness of the data behind it — treat any hard-coded IP in a write-up (including this one) as a snapshot, not a permanent fact, and re-verify with dig or nslookup before relying on it.

3. Counting the round trips

On a fully cold cache, that worked trace costs four network round trips in total: three between the recursive resolver and the DNS hierarchy — root, then .com TLD, then example.com's authoritative server — plus one between the stub resolver and the recursive resolver to carry the final answer back to the client. On a warm cache, some or all of those hierarchy round trips are skipped, because the resolver already holds a cached referral or a cached answer within its TTL window; a fully warm cache costs just the one stub-to-resolver round trip.

4. DNS caching and TTL (Time To Live)

To avoid repeating this walk for every request, resolvers and servers cache the results of previous queries. When a resolver receives a query, it first checks its cache; if the answer is already there, it returns it immediately without contacting any other server, saving both time and network traffic.

Each DNS record carries a Time To Live (TTL) value, measured in seconds, that specifies how long the record may be kept in cache. Once the TTL expires, the cached entry is discarded so that stale information isn't served — which is exactly why a zone operator who changes infrastructure (as in the example.com case above) can rely on old answers aging out of caches worldwide within one TTL window.

5. Negative caching

Negative caching stores the non-existence of a record. When a resolver queries for a domain or record type that doesn't exist, it caches that negative result (governed by its own TTL, taken from the zone's SOA record) so that repeated queries for the same non-existent resource don't hit the authoritative servers again. This reduces load on the DNS hierarchy and improves overall lookup performance, just as positive caching does for records that do exist.

Sources: RFC 1035 (Domain Names — Implementation and Specification); RFC 2308 (Negative Caching of DNS Queries); live dig queries against the public root, .com TLD, and example.com name servers, verified July 2026; Cloudflare and Google Public DNS operator documentation on resolver behavior and caching.