Table of Contents
Understanding Recursive DNS Queries
Recursive queries are one of the key behaviors that make DNS easy to use for people and applications. When you type a website name into your browser, recursive queries are usually what happen behind the scenes to turn that name into an IP address.
This chapter focuses on what makes a query recursive, how it behaves, and how it differs from other query types. The broader DNS system, record types, and hierarchy are covered in other chapters, so here we concentrate only on the recursive aspect.
What “Recursive” Means in DNS
In everyday language, “recursive” can sound complicated. In DNS, the idea is actually simple. In a recursive query, a DNS server takes full responsibility for finding the final answer for the client. The client asks once, and the recursive server does all the follow‑up work on behalf of the client.
The client does not need to know which name servers to contact next. It does not need to understand the DNS hierarchy or cache anything. It only needs to know the IP address of at least one recursive DNS server, often called a “resolver.”
A recursive query asks a DNS server to return a final answer (either a result or an error). The server must not reply with “ask someone else.” It either finds the answer or tells you it cannot be found.
In contrast, in a non‑recursive or iterative query, a DNS server can reply with a referral, which means “I do not know, but try this other server.”
Who Performs Recursive Queries
Most end devices such as laptops, phones, smart TVs, and servers do not perform the full DNS search themselves. Instead, they send recursive queries to a resolver. This resolver can be:
| Type of recursive resolver | Typical example | Managed by |
|---|---|---|
| Local router / gateway | Home Wi‑Fi router | Your home or small office |
| ISP resolver | DNS servers provided by your Internet provider | Your ISP |
| Public resolver | 8.8.8.8 (Google), 1.1.1.1 (Cloudflare) | Public DNS service |
| Enterprise resolver | Internal DNS servers in a company | Corporate IT team |
Your device is usually configured with one or more recursive resolvers either manually or through DHCP. From the device’s point of view, these resolvers behave like a “DNS black box” that always tries to give complete answers.
How a Recursive Query Behaves
When your device sends a recursive query, it sets a specific flag in the DNS request that means “please recurse.” The recursive resolver then follows a series of steps to find the requested information.
The exact sequence of external lookups belongs to the broader DNS topic, but the important part here is the obligation of the recursive resolver. Once it accepts a recursive query:
- It must either return the requested record or
- It must return an error that indicates the name cannot be resolved or does not exist.
The recursive resolver may contact multiple other DNS servers, follow referrals down the DNS hierarchy, and use caching to speed things up. All this complexity is hidden from the original client.
In a recursive query, the resolver hides the entire DNS search process from the client. The client sees only a single request and a single response.
Recursive vs Iterative Behavior
The difference between recursive and iterative behavior is central to DNS, so it is useful to compare them side by side.
| Feature | Recursive query (client → resolver) | Iterative query (resolver → other DNS servers) |
|---|---|---|
| Who asks | End host (PC, phone, server) | Recursive resolver |
| What is requested | “Give me the final answer for this name” | “Give me what you know or tell me who to ask next” |
| Allowed responses | Final data (or error only) | Data, referral, or error |
| Complexity at requester | Very low, just one query | High, must handle multiple steps and referrals |
| Typical usage | Desktop or mobile asking local DNS resolver | Resolver walking the DNS hierarchy |
From the perspective of an authoritative DNS server, queries from recursive resolvers are usually iterative. The authoritative server answers only based on its own zone or provides referrals, and it does not go on to query other servers on behalf of the resolver.
When Recursive Queries Are Used
In practice, almost every DNS lookup that your applications perform uses recursive queries between your device and a resolver. Examples include:
A web browser loading a website, such as www.example.com.
An email server looking up the MX record for another domain.
A smartphone resolving hostnames for apps or system updates.
In all these cases, the client expects to send a single query and wait for a complete answer. The use of recursive queries makes DNS look simple from the client side.
Recursion and Caching
Recursive resolvers usually store answers in a cache for a limited time. This behavior connects directly with recursive queries.
When a resolver receives a recursive query, it can respond in two ways:
If it has a fresh answer in cache, it sends the answer directly from the cache.
If it does not have a fresh answer, it performs the full resolution process and then stores the result in cache for next time.
This allows recursive resolvers to provide fast responses for popular domains without repeating all the lookup steps for every request.
A recursive resolver can answer a recursive query either from cache or by performing a new lookup. In both cases, the client still sees a single final answer.
The rules that control how long records stay in cache, based on TTL values, are discussed in more detail in the DNS caching chapter.
Security and Policy Around Recursive Queries
Allowing recursion has important security and policy consequences. A resolver that provides recursion to any host on the Internet can be abused in various attacks. For this reason, many DNS servers are configured in one of two roles:
Open recursive resolver, which accepts recursive queries from anyone on the Internet.
Closed or restricted recursive resolver, which accepts recursion only from trusted networks or clients.
On internal corporate networks, recursive resolvers might also enforce policies. For example, they might block certain domains or redirect requests for internal services. These behaviors still build on the basic idea of recursion: the resolver takes full responsibility for handling the request and deciding what the final answer will be.
Recursion Flags in DNS Messages
DNS messages include a flag called RD for “Recursion Desired.” When a client wants a recursive query, it sets the RD flag in the request. The server response includes another flag called RA for “Recursion Available,” which indicates that the server supports recursion.
You do not need to memorize all flags for basic understanding, but it is useful to know that recursion is explicitly signaled in the protocol.
If RD = 1 in a query, the client is asking for recursion.
If RA = 1 in a response, the server is telling the client I can perform recursion.
Tools such as dig and nslookup can show these flags, which helps in troubleshooting DNS behavior.
When Recursive Queries Are Disabled
Some DNS servers are configured not to perform recursion at all. These are usually pure authoritative servers. When they receive a query with the RD flag set, they either:
Return data only if they are authoritative for that domain, or
Return an error indicating that recursion is not available.
This configuration prevents those servers from being used as general purpose resolvers.
For a network designer, it is important to separate roles. Authoritative servers typically should not offer open recursion, and recursive resolvers should not serve as authoritative sources for public domains, unless carefully designed.
Summary
Recursive queries allow DNS clients to offload all the work of finding answers to a resolver. The client asks once, and the recursive resolver either returns the final data or a clear error. This concept is central to how everyday devices use DNS without needing to understand the DNS hierarchy or manage multiple queries.
In later chapters about DNS caching and DNS security, you will see how recursion interacts with performance and how improper use of recursion can create security risks or be used for attacks.