DNS Recursive vs. Iterative Resolution

When your browser needs to find the IP address for a domain name, it doesn't go looking itself. It asks someone else to do the work. That request—and whether the someone else actually does the work or just points you in a direction—is the difference between recursive and iterative DNS resolution.

The Two Questions

Every DNS query is essentially asking one of two questions:

Recursive: "Find me the IP address for this domain. Don't come back until you have it."

Iterative: "What do you know about this domain? If you don't have the answer, who should I ask next?"

Recursive says "handle it for me." Iterative says "point me in the right direction." The entire DNS system is built on this division of labor.

How Recursive Resolution Works

When you type www.example.com into your browser, your computer sends a recursive query to a DNS resolver—typically one provided by your ISP or a public service like Google's 8.8.8.8 or Cloudflare's 1.1.1.1.

Your computer is essentially saying: "I don't want to deal with this. You figure it out."

The resolver accepts this responsibility. It will contact however many servers it needs to contact, follow however many referrals it needs to follow, and only respond to you once it has the complete answer (or can definitively tell you the domain doesn't exist).

You make one query. You get one final answer. Everything in between is the resolver's problem.

How Iterative Resolution Works

Once the resolver has accepted your recursive query, it doesn't turn around and make recursive queries to other servers. Instead, it uses iterative queries to walk through the DNS hierarchy while staying in control of the journey.

Here's what happens when your resolver needs to find www.example.com:

Step 1: The resolver asks a root server, "What do you know about www.example.com?"

The root server responds: "I don't know that specific address, but the .com TLD servers handle .com domains. Here are their addresses."

Step 2: The resolver asks a .com TLD server the same question.

The TLD server responds: "I don't have the final answer, but example.com's authoritative name servers can tell you. Here are their addresses."

Step 3: The resolver asks example.com's name server.

This server has the actual answer: "www.example.com is at 93.184.216.34."

Notice the pattern: with iterative queries, the resolver gets pointed in a direction, follows that direction, gets pointed again, and follows again. It's doing the walking. Each server it contacts just says "try over there" until one finally has the answer.

Why This Division Exists

Your laptop shouldn't need to know how to navigate the DNS hierarchy. It shouldn't need to know about root servers, TLD servers, or how to handle referrals. It just wants an IP address.

Recursive queries let end devices delegate this complexity to a resolver that's built for the job.

But the resolver itself wants control. If it made recursive queries to authoritative servers, it would be delegating decisions about caching, server selection, and failure handling. By using iterative queries, the resolver can:

• Choose which servers to contact based on past performance
• Cache intermediate results (not just final answers)
• Retry failed queries to different servers
• Implement its own timeout and fallback logic

The resolver does the work so your device doesn't have to. The resolver uses iterative queries so it stays in charge of how that work gets done.

The Caching Payoff

This architecture makes caching remarkably effective.

When the resolver walks through the hierarchy for www.example.com, it learns along the way. It caches not just the final IP address, but also:

• Which servers handle .com domains
• Which servers are authoritative for example.com

The next time anyone asks for mail.example.com, the resolver can skip the root and TLD servers entirely. It already knows where to find example.com's authoritative servers.

A busy resolver serving thousands of users builds up extensive knowledge about the DNS hierarchy. Most queries can be answered from cache or with just one or two lookups instead of three or four.

Security Implications

Recursive resolvers do significant work on behalf of clients. This makes them targets.

DNS amplification attacks exploit recursive resolvers by sending spoofed queries that appear to come from a victim's IP address. The resolver does all the work and sends a large response to the victim. For this reason, recursive resolvers should only accept queries from authorized clients—not the entire Internet.

Cache poisoning attacks attempt to inject false records into a resolver's cache. Since resolvers trust the responses they receive during iterative resolution, a malicious response at any step could corrupt the cache. DNSSEC addresses this by adding cryptographic signatures to DNS responses.

If you're running an authoritative DNS server (one that holds the actual records for a domain), disable recursion entirely. Your server should only answer iterative queries about domains it's authoritative for—nothing else.

Seeing It in Action

The dig command with the +trace option shows iterative resolution step by step:

dig +trace www.example.com

You'll see the query walk from root servers to TLD servers to authoritative servers, with each referral visible in the output. This is exactly what your recursive resolver does on your behalf—you're just watching it happen in slow motion.

Configuration

DNS server software lets you control recursive behavior. In BIND:

recursion yes;
allow-recursion { 192.168.1.0/24; };

This enables recursive queries only for clients in the specified network. Everyone else gets refused or must use iterative queries.

For an authoritative-only server:

recursion no;

This prevents the server from doing recursive work for anyone, reducing load and eliminating a potential attack vector.

Troubleshooting

Slow DNS resolution usually points to the recursive resolver. It might be overloaded, have poor connectivity to upstream servers, or lack sufficient cache. Try a different resolver or deploy a local caching resolver.

Resolution failures for specific domains suggest a problem in the iterative chain. Use dig +trace to see where the resolution breaks down. Is the TLD server returning the wrong authoritative servers? Is the authoritative server unreachable?

Unexpected recursive service from an authoritative server means recursion wasn't properly disabled. This wastes resources and exposes the server to abuse.