Detailed Explanation of DNS Recursive Query vs Iterative Query: Differences and Workflow

I. Knowledge Point Description

DNS (Domain Name System) query is the core process that converts human-readable domain names into machine-usable IP addresses on the internet. This process mainly operates in two modes: Recursive Query and Iterative Query. In simple terms, these describe how the DNS resolver (usually provided by your Internet Service Provider or a public DNS service like 8.8.8.8) interacts with other DNS servers while obtaining the final answer. Understanding the difference between these two modes is fundamental to understanding how DNS works efficiently and in a distributed manner.

II. Core Concept Distinction

Before diving into the workflow, let's clarify several key roles:

1. DNS Resolver: Also known as the "recursive resolver." It receives query requests from clients (like your browser) and is responsible for "legwork," ultimately returning the answer to the client. The commonly used 8.8.8.8 and 114.114.114.114 are recursive resolvers.
2. Root Name Server: There are 13 groups globally (logical groups, with many more physical servers). They know the addresses of the authoritative servers for all Top-Level Domains (TLDs) (e.g., .com, .cn, .net).
3. TLD Name Server: Responsible for managing information about the authoritative servers for all second-level domains under a specific TLD (e.g., .com).
4. Authoritative Name Server: The server that ultimately holds the IP address records for a specific domain (e.g., www.example.com). The domain owner (or hosting provider) maintains it.

Recursive Query and Iterative Query describe the interaction mode not between the client and the local resolver, but between the recursive resolver and other DNS servers.

III. Recursive Query Workflow Explained

In a recursive query, the client makes a demand to the recursive resolver: "You must give me the final answer, or tell me an error if you can't find it; don't make me ask others."
The recursive resolver takes on all the work. It will act on behalf of the client, performing iterative queries with various levels of DNS servers until it obtains the final answer, then returns it to the client all at once.

A Complete Recursive Query Example (Resolving www.example.com):

Assume your computer's DNS is set to 8.8.8.8.

Step 1: Client Initiates a Recursive Query Request

• Your browser wants to access www.example.com.
• The operating system generates a DNS query message, setting the RD bit to 1 (indicating a request for recursive resolution).
• This request is sent to your configured recursive resolver 8.8.8.8.
• The client says to the resolver: "8.8.8.8, please tell me the IP address for www.example.com. I'll wait for your final result."

Step 2: Resolver Checks Local Cache

• Upon receiving the request, 8.8.8.8 first checks its cache for a valid record for www.example.com. If it exists, it returns it directly to the client, and the process ends. (This is the fastest path.)
• If not, 8.8.8.8 must begin the "resolution journey."

Step 3: Resolver Initiates an Iterative Query (Asks Root Server)

• The resolver doesn't know where www.example.com is, but it knows the addresses of the root servers (these are typically built into the resolver software).
• The resolver initiates an iterative query to a root server: "Please tell me the address of the .com TLD server."
• Note: Here, the resolver acts as a client querying the root server, but root servers typically do not provide recursive service; they only return a "hint."
• The root server replies: "I don't know the specific IP for www.example.com, but I can tell you the IP list of the TLD servers responsible for the .com domain (e.g., the IP for a.gtld-servers.net is 192.5.6.30)."

Step 4: Resolver Continues Iterative Query (Asks TLD Server)

• After obtaining the address of a .com TLD server, the resolver initiates an iterative query to this TLD server: "Please tell me the address of the authoritative server for the example.com domain."
• The TLD server replies: "I don't know the specific IP for www.example.com, but I can give you the NS records and corresponding A records for the authoritative servers of example.com (e.g., the IP for ns1.example.com is 192.0.2.1)."

Step 5: Resolver Performs the Final Iterative Query (Asks Authoritative Server)

• The resolver now has the address of the authoritative server for example.com.
• The resolver initiates an iterative query to this authoritative server: "Please tell me the IP address for www.example.com."
• The authoritative server checks its zone file and finds that the A record for www.example.com is 93.184.216.34.
• The authoritative server replies: "The IP address for www.example.com is 93.184.216.34."

Step 6: Resolver Completes Work, Returns Final Answer to Client

• The resolver finally obtains the final answer 93.184.216.34.
• It returns this result to your computer and saves a copy in its cache (retained for a duration determined by the record's TTL value).
• Your computer receives the IP, and the browser begins establishing a TCP connection with 93.184.216.34.

Summary of Recursive Query Characteristics:

• Simple Client Experience: Only needs to ask once and wait for one final reply.
• High Load on Resolver: It must complete all "legwork" and interact with multiple servers.
• Uses Cache to Improve Efficiency: The resolver's cache can accelerate many subsequent identical queries.

IV. Iterative Query Workflow Explained

In a pure iterative query, the client (or a resolver) must perform the "legwork" itself. The server only returns the best-known result it has, often a referral to the next-level server, and then the client needs to query the next one itself.

A Theoretical Pure Iterative Query Example (Assuming Your Computer is a Full-Featured Resolver Itself):

Step 1: Ask Root Server

• Your computer directly sends a request to a root server (e.g., 198.41.0.4): "What is the IP for www.example.com?"
• The root server replies: "I don't know. Go ask the .com servers. Here is their address list (a.gtld-servers.net, etc.)."

Step 2: Ask TLD Server

• Your computer selects an address from the reply list and sends a request to a .com TLD server: "What is the IP for www.example.com?"
• The TLD server replies: "I don't know. Go ask the authoritative server for example.com. Here is their address (the IP for ns1.example.com is 192.0.2.1)."

Step 3: Ask Authoritative Server

• Your computer sends a request to 192.0.2.1: "What is the IP for www.example.com?"
• The authoritative server replies: "The IP for www.example.com is 93.184.216.34."

Step 4: Obtain Answer

• Your computer obtains the final IP.

Summary of Iterative Query Characteristics:

• Low Load on Servers: Each server only answers the part it knows within its authority; if it doesn't know, it tells you to ask someone else.
• Complex Work for Client (or Initial Querier): Requires handling multiple query round trips.
• In Practice, usually only DNS resolvers use iterative query mode when querying root, TLD, and authoritative servers. Ordinary clients do not perform iterative queries directly.

V. Core Differences and Comparison Table

VI. Summary and Analogy

• Recursive Query is like going to the library's main information desk and telling the librarian: "Please help me find the book 'One Hundred Years of Solitude'." Then you sit and wait. The librarian will go to various shelves, even other branches, to find it for you, and finally hand you the book or tell you it's unavailable.
• Iterative Query is like the librarian telling you: "Fiction is in Section A." You go to Section A and ask the administrator there, who says: "Latin American literature is on Row 3." You go to Row 3 and find 'One Hundred Years of Solitude' yourself.

In the actual DNS resolution process on the internet, these two modes work together: the client sends a "recursive query" to the recursive resolver, and the recursive resolver, to accomplish this task, initiates a series of "iterative queries" on behalf of the client to other servers in the DNS hierarchy. This design perfectly combines user experience (simple for the client) with the system's scalability and distributed nature (controllable load on servers at all levels).