In DNS, what is the difference between a recursive and an iterative query, and which party in a normal lookup sends each kind?
answer
- who does the legwork
- a bit the client sets
- answer, error or referral
- the resolver's work is iterative
- why roots stay non-recursive
basics
~20 sA recursive query (RD set) asks for the final answer or an error, never a referral; an iterative one accepts referrals. Stubs send recursive queries to a recursive resolver, which iterates with non-recursive queries to root, TLD and authoritative servers.
solid answer
~50 sRFC 1034 section 4.3.1 defines two modes. In **recursive mode** the server acts as a resolver for the client and returns "either an error or the answer, but never referrals"; the client asks for it with the **RD** bit, and a server advertises willingness with **RA**. In **non-recursive mode** the server answers from local data only: an answer, an error, or a referral to servers closer to the name. Every name server must support non-recursive queries; recursion is optional. In a normal lookup the **stub** sends a recursive query to its **recursive resolver**, and that resolver then sends **non-recursive** queries to root, TLD and authoritative servers, following each referral itself. So the "recursive resolver" is named for the service it offers its clients; the work it does upstream is iteration. Root and TLD servers normally do not offer recursion: it is optional, and answering only from their own zones keeps them cheap and predictable.
go deeper
Recall that the stub asks one resolver for the whole answer and that resolver does the walking, while root and TLD servers only point onward.
Explain RD and RA, what each mode may return, and why the recursive resolver's upstream work is really a loop of non-recursive queries.
Show how the two modes explain real chains with forwarders, and why a server that answers authoritatively should not also recurse for the world.
Discuss the split as an architecture choice: concentrating recursion in a few caching resolvers keeps authoritative servers simple while sharing cache across many clients.
## Two ways to deal with a question you cannot answer RFC 1034 section 2.3 describes the choice every name server faces when asked about a name held elsewhere: - **Recursive**: the server "pursues the query for the client at another server" and comes back with the result. - **Iterative**: the server "refers the client to another server and lets the client pursue the query". RFC 9499 turns these into the terms used today. A **recursive query** is one with the **RD** (recursion desired) bit set; a **non-recursive query** has RD clear. **Iterative resolution** is what a client does when it repeatedly sends non-recursive queries and follows the referrals and aliases it gets back. ## What each mode may return RFC 1034 section 4.3.1 is precise about the possible replies: | Mode | Possible replies | |---|---| | **Recursive** (RD set and recursion available) | The answer, possibly prefaced by CNAME records; a name error; a temporary error. **Never a referral.** | | **Non-recursive** | An authoritative name error; a temporary error; records that answer the question; a referral to servers "closer" to the name; extra records the server thinks are useful. | Two rules sit behind this table: - **All name servers must implement non-recursive queries.** Recursion "is optional in a name server", and a server may restrict which clients can use it. - **Recursion is negotiated.** The client sets RD; the server sets **RA** (recursion available) in every response to say whether it is willing. RFC 1034 says the client can confirm recursion was used when both RA and RD are set in the reply, and that a server "should never perform recursive service unless asked via RD". The layout of these header bits belongs to the DNS message format. ## Who sends which kind in a normal lookup | Hop | Query sent | What comes back | |---|---|---| | Stub resolver to recursive resolver | Recursive (RD set) | The final answer or an error | | Recursive resolver to a root server | Non-recursive | A referral to the TLD servers | | Recursive resolver to a TLD server | Non-recursive | A referral to the zone's servers | | Recursive resolver to the authoritative server | Non-recursive | The answer, or a statement that the name or type does not exist | So in the classic chain **only the recursive resolver pursues the query**. The stub cannot: RFC 9499 defines a stub resolver as one "that cannot perform all resolution itself". The root, TLD and authoritative servers do not: they answer from their own zone data and stop. ## The naming trap The phrase "recursive resolver" names the **service**, not the algorithm. The resolver is called recursive because it **accepts recursive queries** from its clients and delivers final answers. Upstream, its core algorithm (RFC 1034 section 5.3.3) is a loop of non-recursive queries, with a nested lookup only when it must find a name server's address: 1. Check the cache for the answer. 2. Find the best known servers for the name, walking up towards the root. 3. Send them a query until one responds. 4. If the response is an answer or a name error, cache and return it; if it is a closer delegation, cache it and go back to step 2; if it is a CNAME, change the name and go back to step 1; if the server failed, try another. That loop is iteration. An interviewer who asks "which party truly recurses?" wants to hear that only the recursive resolver pursues queries for others, and that it does so by iterating. ## Why root and TLD servers do not recurse Nothing in RFC 1034 forbids an authoritative server from offering recursion; it is simply optional, and operators of root and TLD servers normally leave it off. The reasons are operational: - **Cost.** A referral is built from local zone data in one step. Recursion means holding state, sending further queries and waiting for them, for every client on the Internet. - **Clean authority.** A server that also resolves on behalf of others fills a cache with data from other zones; keeping authoritative service separate means its replies come only from zones it holds. - **Scale by delegation.** The hierarchy exists so that each level knows only its children. A root server that chased every name would turn the whole namespace's traffic into its own. ## Forwarders in the middle Real deployments often insert a **forwarder** between stub and recursive resolver. RFC 9499 notes that forwarders "often stand between stub resolvers and recursive servers". In that current use, a forwarder accepts recursive queries and typically passes them upstream as recursive queries rather than iterating itself, so the iteration still happens at the recursive resolver at the end of the chain.
- How can a DNS client tell whether a server actually performed recursion for it?RFC 1034 section 4.3.1 says recursive mode was used when both RD and RA are set in the reply. RA on its own is not proof: a willing server sets it in every response, whether or not the query asked for recursion, because it signals availability rather than use.
- What does a DNS server that does not offer recursion do with a query that has RD set?It answers as it would a non-recursive query, from local data: the records if it holds them, a referral to closer servers, or an error. It clears RA, so the client learns recursion was unavailable. RFC 1034 lets a server offer recursion to some clients and refuse it to others.
- Where does a DNS forwarder sit, and does it iterate?A forwarder usually sits between stub resolvers and a recursive resolver, often to share one larger cache. It accepts recursive queries and sends recursive queries upstream instead of walking the tree, so the iteration still happens at the recursive resolver. RFC 9499 notes that RFC 2308's original definition described something slightly different.
saying these in an interview costs you the question
- An iterative query means the stub resolver walks root, TLD and authoritative itself.
- Root servers resolve names recursively for anyone who sets the RD bit.
- The RA bit in a query is how a client asks for recursion.
- A recursive resolver sends recursive queries to the authoritative servers.
- A server in recursive mode may return a referral when it gives up.