Two Query Styles, One Lookup
The distinction is entirely about who does the work:
- A recursive query says: "Give me the final answer. Go and find it; do not come back to me with a half-answer." The server receiving it takes on full responsibility for returning either the requested record or a definitive error.
- An iterative query says: "Tell me the best you know right now." The server replies with either the answer (if it happens to have it) or, more often, a referral — "I don't know, but ask this other server." The asker then follows the referral itself.
The everyday lookup uses both. Your computer (the stub resolver) sends a single recursive query to its configured recursive resolver. That resolver then performs a sequence of iterative queries on your behalf, climbing down the DNS hierarchy until it has the answer to hand back. You make one easy request; the resolver does all the legwork.
Following an Iterative Walk Down the Hierarchy
Say you visit www.example.com and nothing is cached. After receiving your recursive query, the resolver works iteratively:
- Ask a root server. "Where is
.com?" The root does not knowwww.example.com, but it refers the resolver to the.comTLD nameservers. - Ask a
.comTLD server. "Where isexample.com?" The TLD server refers the resolver to the authoritative nameservers for that domain. - Ask the authoritative server. "What is the address record for
www.example.com?" This server actually holds the zone and returns the IP address. - Return the answer. The resolver hands the final IP back to your device, completing the recursive query it was given.
Each step in the middle is an iterative query answered with a referral, not the final record. The resolver is the one chasing those referrals down — your device never sees them. This is the same four-step journey described in how DNS works, viewed through the lens of who is querying whom.
Side by Side
| Recursive query | Iterative query | |
|---|---|---|
| Who asks | Your device → its resolver | The resolver → root, TLD, authoritative |
| Expected reply | The final answer (or a definitive error) | The answer or a referral to ask elsewhere |
| Who follows up | The resolver does the chasing | The asker (resolver) follows each referral |
| Workload | Pushed onto the resolver | Spread across the hierarchy, step by step |
Why DNS Splits the Work This Way
It would be possible for every device to perform its own iterative resolution, but it would be wasteful. Concentrating the iterative work in a shared recursive resolver brings two big wins. First, it keeps client devices simple — they fire one query and wait. Second, and far more important, it lets the resolver cache answers and reuse them for everyone it serves. The root and TLD servers also stay protected: by design they only answer iterative queries with referrals and refuse to do recursion for arbitrary clients, which keeps that critical top tier lean and resistant to abuse.
Caching: The Step That Skips the Walk
In practice, most lookups never trigger a full iterative walk at all. After resolving a name, the resolver stores the answer for as long as the record's TTL permits. The next person to request the same name gets an instant cached reply — no root, no TLD, no authoritative round trips. The resolver may also cache the intermediate referrals, so even a partly-cached lookup skips the upper steps. This is why the first visit to an uncached domain feels marginally slower than every visit after it, and why DNS changes take time to propagate: old answers linger in resolver caches until their TTL expires. The choice of resolver matters here too, since a fast, well-located one shortens both the iterative walk and the cache lookups — see fastest DNS servers.
Frequently Asked Questions
What is the difference between recursive and iterative DNS queries?
In a recursive query the resolver does all the work and returns a final answer. In an iterative query each server gives its best answer — usually a referral to the next server — and the asker follows those referrals itself. Clients query recursively; resolvers query iteratively.
Is DNS recursive or iterative?
Both, at different stages. Your device sends a recursive query to its resolver; the resolver then performs iterative queries against root, TLD, and authoritative servers to find the answer.
What is a recursive resolver?
The DNS server your device queries directly, often run by your ISP or a public provider. It accepts a recursive query, does the iterative legwork, caches the result, and returns the final answer.
Why don't clients do iterative queries themselves?
They could, but centralising iterative resolution in a resolver allows caching across many clients, so most lookups never walk the hierarchy. It also keeps client devices simple and fast.
How does caching change DNS resolution?
If the resolver holds a valid, unexpired answer it returns it immediately with no iterative queries. Each record's TTL controls how long it may be cached, which is why repeated lookups are faster than fresh ones.