When an application needs DNS information, it usually asks one server and expects that server to return a usable result. The server receiving that request may need to contact several other DNS servers before it can respond.

Those two interactions use different resolution models:

A typical lookup uses both. A laptop sends a recursive query to a recursive resolver, and that resolver follows the DNS hierarchy through a series of iterative queries.

Understanding which party is responsible for the next step is the key to understanding the difference.

A normal lookup involves several logical roles.

The roles are more important than the number of machines involved. Two roles can run on the same system, and one logical service can be distributed across many systems.

Application

The application needs information associated with a name such as api.example.com. It normally uses an operating-system or language runtime API rather than constructing DNS messages itself.

Stub Resolver

The stub resolver is a small DNS client on the application's device. It knows how to send a query to a configured DNS server and return the response to the application.

A stub resolver generally does not know how to start at the root, interpret a chain of referrals, choose authoritative servers, and retry the entire process. It delegates that work to a recursive resolver.

Recursive Resolver

The recursive resolver, also called a recursor, accepts a question and works toward a final result. It may be operated by:

From the client's perspective, this server is its DNS service. The client does not need to know which authoritative servers were contacted behind the scenes.

Authoritative Name Servers

An authoritative name server publishes data for one or more DNS zones. Root servers, top-level-domain servers, and the servers responsible for example.com are all authoritative for different portions of the namespace.

Authoritative servers answer from the zones they serve. They do not normally perform open-ended resolution on behalf of arbitrary clients.

In a recursive query, the requester asks the server to take responsibility for completing the lookup.

Conceptually, the request says:

The recursive resolver can satisfy the request in several ways:

The requester waits for one result from the recursive resolver. It does not follow referrals itself.

This is the contract most client devices expect. A backend process may appear to make one DNS request, while the resolver performs several network exchanges to answer it.

When recursive service is accepted, the response contains an answer or an error rather than a referral for the client to pursue.

Recursion Desired and Recursion Available

DNS expresses the recursion request through header flags.

The requester sets the Recursion Desired, or RD, flag:

This asks the receiving server to use recursion if the server supports and permits it.

In a response, the Recursion Available, or RA, flag indicates whether the server offers recursive service:

Together, these flags negotiate recursive mode. The response preserves the request's RD value. A response with both RD=1 and RA=1 confirms that the server made recursive service available for that request.

Setting RD=1 does not force an authoritative server to become a recursive resolver. The server can answer from its own authoritative data, refuse recursion, or report that recursion is unavailable.

Even when both flags are set, they do not prove that the server contacted the hierarchy for this particular response. It may already have had the information needed.

In iterative resolution, the requester asks a server for the best answer it can provide without requiring that server to continue the search.

Conceptually, the request says:

The server can respond with:

If the response is a referral, the requester chooses a referred server and sends the next query. The requester remains responsible for progressing through the hierarchy.

Root and TLD servers normally participate this way. A root server does not chase .com, example.com, and api.example.com on the requester's behalf. It returns information that directs the requester toward the .com authorities.

There Is No “Iterative” Header Flag

DNS has an RD flag to request recursion, but it does not have a separate “iterative query” flag.

An iterative lookup is performed through a sequence of queries for which recursion is not requested:

However, RD=0 alone does not mean the response must be a referral. A server may already be authoritative for the requested name or may already have an applicable answer. In those cases, it can return the answer immediately.

The term iterative resolution therefore describes the requester's behavior across a series of queries, not a distinct DNS message format.

Assume a client wants address information for:

Also assume that the recursive resolver does not already have information that lets it answer immediately. The simplified flow is:

Each stage has a different responsibility.

1. The Application Calls the Local Resolver

The application asks its local resolver API to resolve api.example.com. It does not need the addresses of root or authoritative servers.

2. The Stub Sends a Recursive Query

The stub sends the DNS question to its configured recursive resolver with recursion requested. The resolver's address may have been configured manually, supplied by the local network, or provided by the execution environment.

3. The Recursive Resolver Contacts a Root Authority

The resolver knows how to reach the root through bootstrap configuration. It sends a non-recursive query.

The root is not authoritative for api.example.com, so it returns a referral toward the .com zone. The referral identifies .com authoritative servers and may include the address information needed to contact them.

4. The Resolver Contacts a .com Authority

The .com server is authoritative for the .com zone, but not for the contents of example.com. It returns a referral to the servers responsible for example.com.

5. The Resolver Contacts an example.com Authority

The example.com server is authoritative for the requested name in this simplified case. It returns the requested result as an authoritative answer.

If a more specific child zone had been delegated, this server would instead return another referral, and the resolver would continue.

6. The Resolver Returns One Final Response

The recursive resolver sends the completed response to the stub, and the stub returns it to the application.

From the application side, the entire process looked like one lookup. From the recursive resolver side, it was a controlled walk through multiple authorities.

The name:

contains several labels, but the resolver does not automatically query a different server for each one.

Queries follow delegation boundaries, not dots alone. If the example.com zone contains all data beneath prod.internal.example.com, its authoritative server can answer directly. If internal.example.com is a separate delegated zone, the example.com server returns a referral to that child.

The number of iterative steps therefore depends on zone structure, not simply on hostname length.

The resolver also does not necessarily begin at the root for every lookup. It may already know how to reach an authority from earlier work. The cold-resolution sequence is the clearest way to understand the hierarchy, but real resolvers often start closer to the destination.

The words answer and referral describe different outcomes.

An answer contains information intended to satisfy the question. It may come from an authoritative server or from a recursive resolver that obtained the data earlier.

A referral does not satisfy the original question. It identifies name servers that are closer to the responsible zone, allowing an iterative requester to continue.

An authoritative answer comes from a server using the zone data for which it is responsible. DNS responses can use the Authoritative Answer, or AA, flag to indicate this:

A recursive resolver's final response to a client is not automatically authoritative. The resolver may have obtained the data from an authoritative server, but it is responding in its resolver role rather than serving the original zone.

This distinction matters when interpreting DNS behavior:

Not every server that accepts recursive queries performs the full walk from the root itself.

A forwarding resolver sends queries with recursion requested to another resolver, called an upstream resolver. For example:

The application still receives recursive service. The difference is where the iterative work happens.

A small office router often behaves as a DNS forwarder. Devices send queries to the router, and the router passes them to an ISP or public recursive resolver. A company may also forward public-domain queries upstream while handling its private zones through internal authoritative servers.

A full-service resolver operates recursively with a cache and can contact the authoritative hierarchy itself. A resolver configured to forward depends on another recursive service for at least some questions. One resolver can use both behaviors, resolving some namespaces directly and forwarding others according to policy.

Forwarding adds an extra dependency. If two resolvers are accidentally configured to forward the same query to each other, they can create a forwarding loop in which neither reaches an authority. Careful configuration must ensure that every forwarded path eventually reaches a resolver capable of completing the lookup.

Clients could theoretically implement the full iterative process, but ordinary systems use recursive resolvers for practical reasons.

Simpler Client Software

The stub needs to send questions, receive responses, and handle basic failures. It does not need root hints, referral processing, authority selection, or full retry logic.

Shared Work

Many clients ask for the same popular names. A shared resolver can reuse recently obtained information instead of forcing every device to repeat the complete authority walk. This reduces lookup latency and traffic toward authoritative infrastructure.

Centralized Network Policy

Organizations can apply DNS routing rules, access controls, logging, and private-name handling at a recursive resolver rather than configure every application separately.

Controlled Failure Handling

A recursive resolver can retry another authoritative server when one endpoint is slow or unavailable. The client interacts with one stable service while the resolver manages upstream choices.

These benefits make the recursive resolver part of the application's dependency chain. If the resolver is unreachable or overloaded, applications can fail to resolve names even when the destination's authoritative DNS is healthy.

An authoritative server has a bounded responsibility: publish the zones it serves. Recursive service has a different workload because it accepts arbitrary names and contacts other servers to answer them.

Keeping the roles separate provides several benefits:

Some DNS software can provide authoritative and recursive service in one process, but that capability does not make the roles identical. Public authoritative servers commonly disable recursion for general clients.

An authoritative server may still answer a recursive query from its own zone. If it already has the authoritative data, it can return that data without performing recursion. The presence of RD=1 does not prevent a direct authoritative answer.

The most useful comparison is to ask who must continue after an incomplete response.

In recursive resolution:

In iterative resolution:

This means a recursive resolver is a server to the stub but a client to authoritative servers. It receives one recursive request, then generates several iterative requests.

The terms describe interactions, not permanent properties of every DNS message path. The same system can accept recursive requests from trusted clients, answer directly for a local zone, forward some requests upstream, and use iterative queries for others.

The recursive and iterative layers can fail independently.

The stub cannot reach its recursive resolver. The lookup fails before any root or authoritative server is contacted.

The recursive resolver cannot reach authoritative infrastructure. The client can reach its configured DNS server, but that server cannot complete the work and returns an error or times out.

A referral points to unreachable servers. The resolver progresses partway through the hierarchy but cannot contact the next authority.

An authoritative server does not offer recursion. This is normal. A client that mistakenly uses it as a general-purpose resolver may receive referrals, refusals, or answers only for the server's own zones.

A forwarder cannot reach its upstream resolver. Clients may see a general DNS failure even though both the local forwarder and the destination authority are running.

Forwarders form a loop. Each server passes the query to another without any server performing the authoritative lookup.

One authority endpoint fails. A recursive resolver can often try another server listed for the same zone. Failure of one endpoint is not necessarily failure of the zone.

Locating the failure requires identifying the role of each server in the path. An IP address labeled simply “DNS server” might be a stub target, a forwarding resolver, a full-service resolver, an authoritative server, or a system combining several roles.

Recursive and iterative resolution are not competing end-to-end designs. A normal lookup commonly uses recursion between the stub and resolver, then iteration between the resolver and authoritative servers.

A recursive query does not mean the client contacts every DNS server. The recursive resolver performs that work on the client's behalf.

An iterative query is not a query repeated at fixed intervals. “Iterative” means the requester follows referrals through successive authorities.

There is no dedicated iterative-query flag. Iterative resolution normally uses queries with recursion not requested.

RD=1 is a request, not a command. A server can decline or lack recursive capability.

RA=1 describes availability, not proof of work. The server may answer without contacting any upstream authority.

A non-recursive response is not always a referral. The queried server may already have an applicable or authoritative answer.

Authoritative servers are not general-purpose resolvers. Their primary job is to publish data for their zones.

A long domain name does not necessarily require many referrals. Iterative steps follow zone delegations rather than every label.

A recursive resolver does not necessarily start at the root. It can begin with information it already has, even though the root remains the bootstrap authority for a cold lookup.

Forwarding and recursion can coexist. A server can provide recursive service to its clients while delegating the actual work to an upstream resolver.

A stub resolver normally asks a recursive resolver for a completed answer or error. On a cold lookup, that resolver follows referrals through the root, TLD, and relevant domain authorities, making iterative queries until it reaches authoritative data. Resolution follows delegation boundaries, not every dot in the name.

The RD flag requests recursion, and RA reports that the server offers it. Iterative resolution has no separate flag; it simply consists of queries that do not request recursion. Referrals identify the next authority, while authoritative answers come from a server responsible for the zone.

A forwarder passes recursive work upstream, whereas a full-service resolver contacts the hierarchy itself. Recursive and authoritative service remain separate roles even when one software package provides both.

The client asks one resolver to finish the job, and that resolver follows the chain of authority to a final result.