Skip to content

DNS resolution process

The DNS records module put it off twice. The introduction to that module promised "that resolution walk, root servers through authoritative servers, belongs to its own module later in this course," and the NS record article deferred the same thing again once delegation was on the table. This is that walk — what actually happens, host by host, between a browser asking for www.example.com and a packet leaving with the right destination address.

The cast of characters

A DNS lookup rarely involves just two machines. Four distinct roles show up, and keeping them straight is most of what makes the rest of this article make sense:

  • Stub resolver — a small piece of software built into the operating system, not a full DNS server. It doesn't know how to walk the DNS hierarchy itself; all it does is package up a query and hand it to whichever recursive resolver is configured, then wait for an answer. On Linux this is usually systemd-resolved, listening locally at 127.0.0.53 — the same address dig and nslookup showed as the SERVER in earlier articles.
  • Recursive resolver — the DNS server that actually does the work: your ISP's resolver, a home router's forwarder, or a public one like 1.1.1.1 or 8.8.8.8. When a stub resolver asks it a question, it promises to come back with a final answer — not a referral, not a "try someone else." Getting there might take several queries of its own.
  • Root name servers — thirteen logical servers, named a.root-servers.net through m.root-servers.net, that answer for the very top of the DNS tree. IANA describes the actual infrastructure behind those thirteen names as "a network of hundreds of servers in many countries around the world" — each of the thirteen names is reachable through many physical machines spread across the globe, all answering to the same address via anycast routing, not thirteen single boxes.
  • TLD and authoritative servers — the root servers don't know anything about example.com specifically. They know which servers are authoritative for .com, and those .com servers in turn know which servers are authoritative for example.com itself. That chain of "I don't know, but I know who does" is delegation, and the NS record article already covered the mechanism — glue records included — that makes each handoff possible.

Recursive resolvers cache; stub resolvers barely do

Before walking the full chain, one detail explains why most lookups never touch it at all: caching. The DNS records introduction covered TTL as the caching lifetime attached to every record, and a recursive resolver is where that TTL actually gets used. The first time anyone asks that resolver for example.com's A record, it does the full walk described below and stores the answer. Every subsequent request for the same name, from any client using that resolver, gets served straight from that cache until the TTL expires — no root query, no TLD query, no authoritative query, just a lookup in local memory. For a busy resolver handling a popular domain, the overwhelming majority of queries never leave the cache at all.

Walking the chain for a name nobody has asked for yet

Assume the worst case: a recursive resolver with an empty cache, asked for www.example.com's A record for the first time. dig's +trace option, already introduced in the command-line tools module, makes this walk visible directly rather than something to take on faith:

dig www.example.com A +trace

;; global options: +cmd
.                       518400  IN      NS      a.root-servers.net.
;; Received 239 bytes from 192.168.1.1#53(192.168.1.1) in 11 ms

com.                    172800  IN      NS      a.gtld-servers.net.
;; Received 833 bytes from 198.41.0.4#53(a.root-servers.net) in 33 ms

example.com.            172800  IN      NS      a.iana-servers.net.
;; Received 168 bytes from 192.5.6.30#53(a.gtld-servers.net) in 27 ms

www.example.com.        86400   IN      A       93.184.216.34
;; Received 56 bytes from 199.43.135.53#53(a.iana-servers.net) in 41 ms

Four steps, each one narrowing the question:

  1. The resolver already knows the thirteen root servers' addresses — every DNS resolver ships with a root hints file listing them, since without a fixed, trusted starting point there'd be nothing to bootstrap the rest of the walk from. It asks a root server for www.example.com. The root server doesn't know the answer, but it knows who's authoritative for .com, and says so.
  2. The resolver asks that .com server for www.example.com. The .com server doesn't have the A record either, but it does have example.com's delegation — the NS records naming example.com's own authoritative servers — and refers the resolver there.
  3. The resolver asks one of example.com's authoritative servers for www.example.com. This server actually holds the zone file, and this time the answer is the real thing: an A record, not another referral.
  4. The resolver hands that A record back to the stub resolver that asked in the first place — and caches it locally for as long as its TTL allows, so the next request for the same name skips straight to step 4.

Every one of those four queries traveled over UDP, sent to port 53 — the TCP vs UDP comparison already showed exactly this kind of exchange in a raw packet capture, one query datagram out, one response datagram back, no connection setup at all. UDP's speed is precisely why DNS defaults to it: a resolver doing four separate lookups back to back can't afford a TCP handshake before every single one of them. DNS falls back to TCP only when a response is too large to fit in a single UDP datagram — a full zone transfer between name servers, or a response padded with DNSSEC signatures — a case RFC 1035 anticipates directly rather than treating as an exception nobody planned for.

Two different behaviors hiding inside one walk

Look closely at the four steps above and a distinction emerges that matters enough to get its own two articles. The resolver did all the asking — it went to the root, then to .com, then to example.com's own servers, one query at a time, following each referral itself. But the root, TLD, and authoritative servers each did something different: they answered with either the final record or a referral, and none of them went and asked anyone else on the resolver's behalf.

Those are two distinct modes of answering a DNS query, and the terms for them come straight from the protocol's control bits — the flags line dig's output already showed in the command-line tools module, specifically the rd (recursion desired) and ra (recursion available) bits:

  • A server offering a recursive lookup takes full responsibility for getting a final answer, chasing referrals on the client's behalf if it has to.
  • A server offering only an iterative lookup gives back the best answer it has right now — the real record, or a referral to someone better positioned to answer — and stops there.

Recursive lookup and iterative lookup each take one of those two behaviors apart in more depth than fits here: what a server actually promises when it enables recursion, what goes wrong when it's enabled somewhere it shouldn't be, and how the referral-following behavior visible in the +trace output above maps onto the iterative role the root, TLD, and authoritative servers all played in the walk.

Sources