DNS glossary

What is a recursive query?

A recursive query is a DNS request that asks a name server to return either the complete answer or an error, rather than a referral. The server resolves the name on the client's behalf, querying other authoritative servers as needed, as described in RFC 1034.

Let's simplify your DDI
Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button
Key takeawaysKey takeaways are generated with AI assistance. Because automated summaries can occasionally contain errors or miss important context, always refer to the full blog post for complete information.

A recursive query is a DNS request where the queried name server performs full name resolution on the client's behalf and returns either a final answer or an error, as opposed to a referral. The client signals this intent by setting the recursion desired (RD) flag in the DNS message header, and the resolver contacts other authoritative servers as needed, caching results and returning only the final outcome. Recursive resolvers are critical to application performance and availability, but require careful security hardening through access control lists to prevent abuse as open resolvers in denial-of-service attacks and protection against cache poisoning.

  • Recursive resolvers must restrict recursion to known internal client ranges using access control lists to prevent exploitation as open resolvers for reflection and amplification attacks.
  • The resolver’s cache hit rate and availability directly determine application performance and user experience, since nearly every DNS lookup from an end device begins as a recursive query routed through the resolver.
  • Common misconfigurations include undersized resolver capacity, unreachable forwarders, stale conditional forwarding rules, and missing query logging, which can cause slow lookups after cache flushes or SERVFAIL errors when authoritative server delegations are broken.

Recursive query at a glance

AttributeValue
Full nameRecursive query
CategoryDNS query type
Defined inRFC 1034 and RFC 1035, with resolver behavior updated in later RFCs
Protocol and portDNS over UDP and TCP, port 53
OSI layerLayer 7 (application)
Primary useLetting stub resolvers get a final answer from a recursive resolver without following referrals themselves
Related termsIterative query, Recursive resolver, Stub resolver, Authoritative name server, DNS caching

How recursive query works

In a recursive query, the client sets the recursion desired (RD) flag in the DNS message header. The receiving server, if it offers recursion, takes on the work of resolving the name and returns only the final result.

  1. Client sends the query: A stub resolver on the client sends a query with the RD flag set to its configured recursive resolver.
  2. Resolver checks its cache: The recursive resolver looks for a valid cached answer. If one exists, it returns it immediately.
  3. Resolver queries other servers: On a cache miss, the resolver sends iterative queries, usually starting at a root server. It follows referrals to top-level domain servers and then to the authoritative server for the zone.
  4. Resolver caches the result: The resolver stores the answer for the time given by the record's time to live (TTL).
  5. Resolver replies to the client: The resolver returns the final answer, or an error such as NXDOMAIN or SERVFAIL, with the recursion available (RA) flag set.

The client sees one request and one response, however many servers the resolver contacts. A server may refuse recursion, in which case it answers only from its own data or returns a referral or refusal. Authoritative-only servers typically do not offer recursion.

Why recursive query matters in enterprise networks

Nearly every DNS lookup an end device makes begins as a recursive query, so the recursive resolver sits in the path of almost all application traffic. Its performance, cache hit rate and availability directly affect how fast and how reliably users reach services. If the resolver is slow or down, applications appear to fail even when the network and servers are healthy.

Recursion also carries security implications. A resolver that accepts recursive queries from any source on the internet is an open resolver, which attackers can abuse for reflection and amplification denial-of-service attacks. Restricting recursion to known client networks is a standard hardening step. Resolvers are also targets for cache poisoning, which DNSSEC validation, source port randomization and query ID randomization help mitigate.

Poor management shows up in several ways: resolvers with undersized capacity, forwarders that point to unreachable servers, stale or inconsistent conditional forwarding rules, and missing query logging that leaves no record of what clients looked up. Separating recursive resolvers from authoritative servers, as is common practice, keeps each role simpler to secure, scale and monitor.

Recursive query vs Iterative query

A recursive query asks the server to do all the work and return a final answer or an error, while an iterative query lets the server return its best partial answer, such as a referral to another name server. What is Iterative (or non-recursive) query?

AttributeRecursive queryIterative query
Who does the resolution workThe queried serverThe querying client or resolver
Typical responseFinal answer or errorAnswer or referral to a closer name server
RD flag in querySetNormally not set
Typical senderStub resolver to recursive resolverRecursive resolver to authoritative servers
Server must support recursionYesNo

Common recursive query issues

A resolver that answers recursive queries from any source address can be used in reflection and amplification attacks. Restrict recursion with access control lists to internal client ranges and check that it is not reachable from the internet.

Clients receive REFUSED responses when their subnet is missing from the resolver's allowed list. This often appears after a new subnet is deployed and the access list is not updated.

After a restart or cache flush, every query becomes a cache miss and triggers a full walk from the root. Users see slow page loads until the cache warms again.

When an authoritative server for a zone is unreachable or returns lame delegations, the resolver cannot finish resolution and returns SERVFAIL. The client only sees a failure, so the fault is found by tracing the iterative queries on the resolver.

A resolver keeps answers until the TTL expires, so a changed record may not appear for some clients. Engineers see inconsistent results between resolvers after a change until caches expire or are flushed.

See how unified DDI simplifies network operations

Manage DNS, DHCP and IP addresses from one platform with automation, visibility and control built in.

Talk to us

Recursive query FAQ

Related terms

Article

Recursive DNS server

Responsible for providing the proper IP address of the intended domain name to the requesting host; the first servers contacted as the result of a request.

Learn more
Article

Iterative (or non-recursive) query

A DNS request that states, “Give me the answer or give me any information that will help me find the answer.” The nameserver will respond back from its cache or zone files but will not contact other DNS servers.

Article

Caching DNS server

A server that handles recursive requests from clients.

Learn more
Article

DNS stub resolver

The part of the client device that facilitates DNS queries.

Learn more
Article

DNS query / DNS request

Demand for information sent from a user’s computer (DNS client) to a DNS server.

Learn more
Article

Authoritative DNS server / Authoritative name server

Provides original and definitive answers to DNS queries.

Learn more
Article

Time to Live (TTL)

A setting for each DNS record that specifies how long a resolver is supposed to cache the DNS query before it expires.

Learn more
Article

DNS tunneling

Exploits the DNS protocol to tunnel malware and other data through a client-server model.

Learn more
Browse the full glossary