Iterative vs. Recursive Resolution

In one line: the hierarchy tells you where the answers live. This lesson is about who does the walking — and the answer determines where load lands in the world's most heavily queried system.

Iterative resolution

The local server queries the root, TLD, and authoritative servers sequentially, taking responsibility for navigating the hierarchy. Each server it asks responds with a referral — not the answer, but the address of who to ask next.

The local server does all the work and holds all the state. Every other server answers one simple question and forgets about it.

Recursive resolution

The client queries the local server, which then queries the root. The root forwards the request to the next level, and so on — the burden of resolution is passed from server to server, with the answer travelling back down the same chain.

Each server holds the request open while waiting for the one below it — so state accumulates at every tier simultaneously.

The comparison

Aspect	Iterative	Recursive
Who navigates	The local server	Each server in turn
What upstream servers return	A referral to the next tier	The final answer
Load on root and TLD servers	Low — answer one question and forget	High — hold state until the chain completes
Where results get cached	The local server sees every intermediate referral and caches them	Mainly the endpoints
Client complexity	Higher for whoever iterates	Minimal — ask once, get an answer
Typical use	Resolver to the hierarchy	Client (stub resolver) to its local resolver

Iterative is preferred, and here's the reason

Iterative queries are typically preferred to reduce the processing load on the central DNS infrastructure.

The root and TLD servers are shared global infrastructure serving the entire internet. Under recursion they would have to hold open state for every in-flight query passing through them — an enormous burden that scales with total internet traffic. Under iteration they answer one cheap referral and immediately forget the requester, which is both stateless and trivially cacheable.

This is a general distributed-systems pattern worth naming: push work to the edge and keep shared infrastructure stateless. The same reasoning appears in load balancer and CDN design.

Real deployments use both

The split is deliberate: the client wants one question and one answer, and the resolver wants control over each hop so it can cache every intermediate result. Recursion once, iteration many times.

The two are not competing options at the system level — they are used at different segments of the same lookup:

Your laptop's stub resolver does not want to walk the hierarchy — it makes a single recursive request to the configured resolver and waits for a final answer. The resolver then performs iterative queries up the hierarchy on its behalf.

This split is why the local resolver is such an effective cache: because it sees every intermediate referral, it caches not just the final answer but the TLD and authoritative server addresses too — which is what lets later lookups skip tiers entirely, as the next lesson shows.

Key takeaway

Iteration keeps shared global infrastructure cheap and stateless; recursion keeps clients simple. Real DNS uses recursion at the edge and iteration in the core — the opposite arrangement would not survive internet-scale traffic.

Interview signal by level

Level	What a strong answer sounds like
L4	Can define both terms.
L5	Knows the preference: "iterative is used upstream so root and TLD servers aren't overloaded."
Staff+	Describes the hybrid and generalizes it: "recursive from stub to resolver, iterative from resolver up. Keeping shared infrastructure stateless is the same principle behind edge caching generally — and it's why the resolver ends up caching intermediate referrals, not just answers."

Next: the layer that means most lookups never reach the hierarchy at all.