DNS Resolution
Iterative Resolution
Read aloud is unavailable in this browser.
The Server-to-Server Protocol
We've seen how recursive resolution shields clients from complexity—send one query, get one answer. But what happens inside the recursive resolver? How does it navigate from root servers to TLD servers to authoritative servers to obtain that answer?
The answer is iterative resolution: a fundamentally different query mode where each server provides the best information it has without taking responsibility for completing the resolution. Instead of "find this for me," iterative queries say "what do you know about this?"
Understanding iterative resolution reveals the true architecture of DNS—a distributed database where knowledge is scattered across millions of servers, each with authoritative information about their own zone and referrals to servers handling other zones.
By the end of this page, you will understand: (1) What iterative resolution means and how it differs from recursive, (2) How referrals work and what information they contain, (3) The step-by-step iterative resolution algorithm, (4) Why authoritative servers use iterative-only responses, and (5) The relationship between iterative and recursive resolution.
Defining Iterative Resolution
Iterative resolution is a DNS query mode where the queried server provides the best answer it can from its own knowledge without querying other servers. If the server doesn't have the complete answer, it returns a referral—a pointer to other servers that are more likely to have the answer.
The key distinction:
| Aspect | Recursive Resolution | Iterative Resolution |
|---|---|---|
| Server responsibility | Complete the entire resolution | Provide best local information |
| Response type | Final answer or error | Answer, referral, or error |
| Query flag | RD=1 (Recursion Desired) | RD=0 (No recursion) |
| Typical usage | Client → Resolver | Resolver → Authoritative servers |
| Analogy | "Find this address for me" | "What do you know about this area?" |
In iterative mode, when a server doesn't have the authoritative answer, it returns a referral response containing NS (Name Server) records pointing to more authoritative servers. The querier must then send a new query to those servers. This "I don't know, but try asking them" pattern is the essence of iterative resolution.
Why "iterative"?
The term reflects the algorithm: the resolver iterates through servers, each time getting closer to the authoritative source:
- Iteration 1: Query root server → Get referral to TLD servers
- Iteration 2: Query TLD server → Get referral to authoritative servers
- Iteration 3: Query authoritative server → Get final answer
Each iteration narrows the search space, moving from the most general (root) to the most specific (authoritative) level of the DNS hierarchy. The number of iterations typically equals the number of levels in the domain hierarchy that aren't cached.
Anatomy of a Referral
Referral responses are the currency of iterative resolution. Understanding their structure is essential for debugging DNS issues and understanding resolution mechanics.
Referral Response Structure:
A referral response has a distinctive format in the DNS message sections:
| Section | Contents | Purpose |
|---|---|---|
| Header | QR=1 (response), RCODE=0 (no error), AA=0 (not authoritative) | Indicates this is a referral, not an authoritative answer |
| Question | Original query (e.g., www.example.com A) | Echoes the query for matching |
| Answer | Empty (no answer yet) | The queried server doesn't have the final answer |
| Authority | NS records pointing to more authoritative servers | Tells the resolver where to ask next |
| Additional | A/AAAA records for the NS servers (glue records) | Provides IP addresses to avoid circular resolution |
Example Referral from Root Server:
When querying a root server for www.example.com, the response looks like this:
;; HEADER:
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
;; QUESTION SECTION:
;www.example.com. IN A
;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 172800 IN A 192.33.14.30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
Breaking this down:
- No Answer section: The root server doesn't know about
www.example.comdirectly - Authority section: Four NS records pointing to
.comTLD servers - Additional section: IP addresses (glue records) for those NS servers
- TTL of 172800: Two days—referrals can be cached for a long time
In referral responses, the AA flag is 0, indicating this server is not authoritative for the queried name. When the resolver finally reaches the authoritative server, the response will have AA=1 and an Answer section with the actual record. This flag tells the resolver it has reached the end of the iterative chain.
Glue Records: Solving the Bootstrap Problem
Glue records in the Additional section solve a critical chicken-and-egg problem. Consider this delegation:
example.com. NS ns1.example.com.
example.com. NS ns2.example.com.
To query ns1.example.com for the example.com zone, you need the IP address of ns1.example.com. But to get that IP address, you'd need to query the example.com zone—which requires knowing where ns1.example.com is!
Glue records break this cycle by including the IP addresses in the parent zone's referral:
;; In .com TLD zone:
example.com. 86400 NS ns1.example.com.
example.com. 86400 NS ns2.example.com.
ns1.example.com. 86400 A 93.184.216.1 ; Glue
ns2.example.com. 86400 A 93.184.216.2 ; Glue
When are glue records required?
- Required: When nameserver names are within the delegated zone (in-bailiwick)
- Optional but helpful: When nameserver names are in sibling zones
- Not provided: When nameserver names are in completely external zones
The Iterative Resolution Algorithm
The iterative resolution algorithm implemented by recursive resolvers follows a precise sequence. Let's trace it step by step for resolving www.subdomain.example.com:
Initialization:
- •Current query: www.subdomain.example.com A
- •Current server list: Root server IP addresses (from root hints file)
- •Zone cut Stack: [. (root)]
Step-by-Step Execution:
Step 1: Query Root Server
Query: www.subdomain.example.com A
To: Root server (e.g., 198.41.0.4 - a.root-servers.net)
Response:
Authority: com. NS a.gtld-servers.net. (+ more)
Additional: a.gtld-servers.net. A 192.5.6.30
The root server says: "I don't know about www.subdomain.example.com, but try the .com servers."
Step 2: Query TLD Server
Query: www.subdomain.example.com A
To: .com TLD server (e.g., 192.5.6.30 - a.gtld-servers.net)
Response:
Authority: example.com. NS ns1.example.com.
Additional: ns1.example.com. A 93.184.216.1
The .com server says: "I don't know about www.subdomain.example.com, but try the example.com servers."
Step 3: Query Authoritative Server
Query: www.subdomain.example.com A
To: example.com nameserver (e.g., 93.184.216.1)
Response (Option A - Direct answer):
Answer: www.subdomain.example.com. A 203.0.113.50
Flags: AA=1 (authoritative)
Response (Option B - Another delegation):
Authority: subdomain.example.com. NS ns.subdomain.example.com.
Additional: ns.subdomain.example.com. A 203.0.113.10
If there's a subdomain delegation, iteration continues. Otherwise, the resolution is complete.
Termination Conditions:
- •Authoritative answer (AA=1): Resolution successful, return the answer
- •NXDOMAIN with AA=1: Domain definitively doesn't exist
- •NODATA (empty answer with AA=1): Domain exists but no records of requested type
- •All servers exhausted: Return SERVFAIL after trying all available servers
- •Loop detected: Some resolvers detect infinite referral loops
- •Iteration limit reached: Typically 20-30 iterations maximum
Why Authoritative Servers Use Iterative Mode
Authoritative DNS servers almost universally refuse recursive queries, responding only in iterative mode. This is a deliberate architectural decision with several important reasons:
- •Separation of Concerns: Authoritative servers manage zone data; recursive servers handle resolution logic. This separation creates cleaner architecture and clearer responsibility boundaries.
- •Resource Protection: Recursion is computationally expensive (requires querying multiple external servers). Authoritative servers would be overwhelmed if they performed recursion for arbitrary queries.
- •Security Posture: Open recursive servers are attack vectors for DNS amplification and cache poisoning. Authoritative servers that refuse recursion eliminate this attack surface.
- •Predictable Performance: Iterative responses have bounded latency (single local lookup). Recursive responses have unbounded latency (depends on external network conditions).
- •Caching Strategy: Authoritative servers don't cache external data; they serve only their own zone data. Recursion would require implementing caching for foreign zones.
- •Serves only its own zone data
- •Returns authoritative answers (AA=1)
- •Provides referrals for subzone delegations
- •No external queries required
- •Simple, fast, predictable
- •Queries external servers on behalf of clients
- •Caches responses from all zones
- •Implements complex resolution logic
- •Handles timeouts, retries, CNAME chasing
- •Manages security (validation, filtering)
Some DNS servers act as both authoritative (for certain zones) and recursive (for certain clients). For example, an internal corporate DNS server might be authoritative for internal.company.com while providing recursion for employee lookups of external domains. In such configurations, careful access control ensures recursion is only provided to trusted clients.
Server Selection Strategies
When a referral provides multiple NS records, the resolver must choose which server to query. This decision significantly impacts resolution performance and reliability.
Selection Algorithms:
1. Round-Robin:
- Simple rotation through the server list
- Provides basic load distribution
- Doesn't account for server responsiveness
2. Random Selection:
- Randomly pick from available servers
- Good for load distribution
- May repeatedly choose slower servers
3. SRTT (Smoothed Round-Trip Time):
- Track response times for each server
- Prefer servers with lower historical latency
- Most modern resolvers use this approach
12345678910111213141516171819202122232425262728293031323334353637383940414243
// Simplified SRTT server selectionclass ServerSelector { // Stored metrics per server serverMetrics: Map<string, { srtt: number, // Smoothed RTT in milliseconds rttVariance: number, // RTT variance for timeout calculation failureCount: number, lastQuery: Date }>; selectServer(servers: string[]): string { // Filter out servers with recent failures const viable = servers.filter(s => this.serverMetrics.get(s)?.failureCount < 3 ); if (viable.length === 0) { // All servers failing, reset and try again servers.forEach(s => this.resetMetrics(s)); return this.randomSelect(servers); } // Sort by SRTT, prefer fastest viable.sort((a, b) => { const srttA = this.serverMetrics.get(a)?.srtt ?? Infinity; const srttB = this.serverMetrics.get(b)?.srtt ?? Infinity; return srttA - srttB; }); // Pick from top candidates (with some randomization to probe) return this.weightedSelect(viable.slice(0, 3)); } updateMetrics(server: string, rtt: number) { const metrics = this.serverMetrics.get(server); if (metrics) { // Exponential moving average const alpha = 0.125; metrics.srtt = (1 - alpha) * metrics.srtt + alpha * rtt; metrics.failureCount = 0; } }}Failure Handling Strategies:
| Failure Type | Immediate Action | Long-term Action |
|---|---|---|
| Timeout | Try next server in NS set | Increase SRTT estimate for failed server |
| SERVFAIL response | Try next server | Mark server as temporarily unavailable |
| REFUSED response | Try next server | May indicate server misconfiguration |
| Network unreachable | Try next server | Mark server as down |
| Truncated response (TC=1) | Retry with TCP | Update protocol preference for server |
Modern resolvers adjust timeout values per-server based on observed RTT. A server consistently responding in 20ms should have a shorter timeout than one averaging 200ms. This prevents both premature timeouts (retrying too soon) and wasted waiting (not failing over quickly enough). The formula often mirrors TCP's RTO calculation: timeout = SRTT + 4 × RTTVariance.
Iterative vs Recursive: The Complete Picture
The DNS resolution system elegantly combines both iterative and recursive paradigms. Understanding their interplay reveals the thoughtful design behind DNS architecture.
The Standard Resolution Flow:
Key Observations:
-
The recursion boundary: Only the client→resolver query is recursive. Everything else is iterative.
-
Flag semantics:
- RD (Recursion Desired): Set by the querier to request recursion
- RA (Recursion Available): Set by the responder to indicate it can perform recursion
- AA (Authoritative Answer): Set when the responder is authoritative for the queried name
-
Different server behaviors:
- Stub resolver: Always sets RD=1, expects complete answers
- Recursive resolver: Accepts RD=1, sends RD=0 to authoritative servers
- Authoritative server: Ignores RD flag, always responds iteratively
| Characteristic | Recursive | Iterative |
|---|---|---|
| Query flag | RD=1 | RD=0 (or RD ignored) |
| Response type | Complete answer or error | Answer, referral, or error |
| Server work | Full resolution path | Single lookup/referral |
| Network round trips | 1 (client perception) | 1 per iteration |
| Client complexity | Minimal | Must follow referrals |
| Server resource usage | High (many external queries) | Low (local data only) |
| Caching benefit | Shared across all clients | Per-resolver only |
| Latency | Variable (depends on cache) | Predictable (local lookup) |
| Use case | Client to resolver | Resolver to authoritative servers |
If recursion simplifies clients, why not have every server perform recursion? The answer is scalability. Root servers receive billions of queries daily. If they had to perform full resolution for each query, they'd need to make potentially 3+ outbound queries per inbound query, creating an impossible load. The iterative model ensures root servers do minimal work—just return a referral from local data.
Troubleshooting Iterative Resolution
Understanding iterative resolution helps diagnose DNS problems. Here are tools and techniques for examining the iterative resolution path:
Using dig with +trace:
The +trace option in dig simulates iterative resolution, showing each step:
123456789101112131415161718
$ dig +trace www.example.com ; <<>> DiG 9.18.1 <<>> +trace www.example.com;; global options: +cmd. 518400 IN NS a.root-servers.net.. 518400 IN NS b.root-servers.net.;; Received 239 bytes from 8.8.8.8#53(8.8.8.8) in 15 ms com. 172800 IN NS a.gtld-servers.net.com. 172800 IN NS b.gtld-servers.net.;; Received 835 bytes from 198.41.0.4#53(a.root-servers.net) in 23 ms example.com. 172800 IN NS a.iana-servers.net.example.com. 172800 IN NS b.iana-servers.net.;; Received 175 bytes from 192.5.6.30#53(a.gtld-servers.net) in 45 ms www.example.com. 86400 IN A 93.184.216.34;; Received 56 bytes from 199.43.135.53#53(a.iana-servers.net) in 112 msInterpreting the output:
- Each section shows a query to a different server
- Lines with
; Received ... bytes from ...show which server responded - The progression: root → .com TLD → example.com authoritative → final answer
- Timing at each step helps identify slow or problematic servers
Common Problems and Diagnosis:
| Symptom | Possible Cause | Diagnosis Command |
|---|---|---|
| Resolution hangs at TLD level | Authoritative servers unreachable | dig @tld-server example.com NS +norec |
| Lame delegation | NS records point to servers not authoritative | dig @ns-server example.com SOA |
| Missing glue records | Can't resolve NS names | dig @parent-server example.com NS |
| +trace works but normal query fails | Recursive resolver issue, not zone issue | dig @8.8.8.8 example.com vs dig +trace |
| Intermittent failures | Some NS servers misconfigured | dig @each-ns example.com A separately |
The dig option +norec (or +norecurse) sends a query with RD=0, simulating how a recursive resolver queries authoritative servers. This helps verify whether an authoritative server is correctly responding with referrals or answers without recursion. Use it when debugging delegation or server configuration issues.
KEEP LEARNING
There’s more to understand.
You’re reading the introduction. Create a free account to read the complete lesson, save notes and keep track of your progress.