Computer NetworksDNS Resolution

DNS Resolution

LevelIntermediate

Duration60 mins

TopicDNS Resolution

2 / 5

Iterative Resolution

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.

What You Will Learn

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?"

The Referral Response

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:

DNS Message Sections in a Referral Response
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.com directly
Authority section: Four NS records pointing to .com TLD servers
Additional section: IP addresses (glue records) for those NS servers
TTL of 172800: Two days—referrals can be cached for a long time

The AA (Authoritative Answer) Flag

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:

Algorithm Initialization

•Current query: www.subdomain.example.com A
•Current server list: Root server IP addresses (from root hints file)
•Zone cut Stack: [. (root)]

Converting Mermaid diagram...

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:

Why Authoritative = Iterative Only

•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.

Authoritative Server Role

•Serves only its own zone data
•Returns authoritative answers (AA=1)
•Provides referrals for subzone delegations
•No external queries required
•Simple, fast, predictable

Recursive Resolver Role

•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)

The Hybrid Exception

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

SRTT Algorithm Concept
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// Simplified SRTT server selection
class 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:

Server Failure Response 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

Adaptive Timeout Calculation

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:

Converting Mermaid diagram...

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

Comprehensive Comparison: Recursive vs Iterative
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

Why Not All-Recursive?

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:

dig +trace example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ 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 ms

Interpreting 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:

Iterative Resolution Troubleshooting
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 +norec Flag

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.

Summary: Iterative Resolution

We've explored iterative resolution in comprehensive detail. Let's consolidate the key concepts:

Key Takeaways

•Iterative queries return best local knowledge — Servers provide answers or referrals from their own data without querying other servers.
•Referrals contain NS records and glue — Each referral points to more authoritative servers and often includes their IP addresses.
•Resolvers iterate through hierarchy — From root to TLD to authoritative, each step narrows the search space.
•Authoritative servers use iterative mode — This separation of concerns protects resources and provides cleaner architecture.
•Server selection affects performance — SRTT-based selection prefers faster servers, improving resolution latency.
•Iterative + recursive complement each other — Clients see recursive simplicity; servers communicate iteratively for scalability.

What's next:

Now that we understand both recursive and iterative resolution modes, we'll examine the complete resolution process end-to-end—tracing a query from user action through every component, exploring caching effects, and understanding how modern optimizations like DNS prefetching work.

Page Complete

You now understand iterative resolution—the server-to-server communication pattern that enables DNS's distributed architecture. Combined with recursive resolution knowledge, you can now trace and debug the complete DNS resolution path. Next, we'll synthesize these concepts into the comprehensive resolution process.

2 / 5

Loading learning content...

Computer NetworksDNS Resolution

DNS Resolution

LevelIntermediate

Duration60 mins

TopicDNS Resolution

2 / 5

Iterative Resolution

The Server-to-Server Protocol

What You Will Learn

Defining Iterative Resolution

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?"

The Referral Response

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

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:

DNS Message Sections in a Referral Response
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.com directly
Authority section: Four NS records pointing to .com TLD servers
Additional section: IP addresses (glue records) for those NS servers
TTL of 172800: Two days—referrals can be cached for a long time

The AA (Authoritative Answer) Flag

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.

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:

Algorithm Initialization

•Current query: www.subdomain.example.com A
•Current server list: Root server IP addresses (from root hints file)
•Zone cut Stack: [. (root)]

Converting Mermaid diagram...

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:

Why Authoritative = Iterative Only

•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.

Authoritative Server Role

•Serves only its own zone data
•Returns authoritative answers (AA=1)
•Provides referrals for subzone delegations
•No external queries required
•Simple, fast, predictable

Recursive Resolver Role

•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)

The Hybrid Exception

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

SRTT Algorithm Concept
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// Simplified SRTT server selection
class 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:

Server Failure Response 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

Adaptive Timeout Calculation

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:

Converting Mermaid diagram...

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

Comprehensive Comparison: Recursive vs Iterative
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

Why Not All-Recursive?

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:

dig +trace example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ 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 ms

Interpreting 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:

Iterative Resolution Troubleshooting
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 +norec Flag

Summary: Iterative Resolution

We've explored iterative resolution in comprehensive detail. Let's consolidate the key concepts:

Key Takeaways

•Iterative queries return best local knowledge — Servers provide answers or referrals from their own data without querying other servers.
•Referrals contain NS records and glue — Each referral points to more authoritative servers and often includes their IP addresses.
•Resolvers iterate through hierarchy — From root to TLD to authoritative, each step narrows the search space.
•Authoritative servers use iterative mode — This separation of concerns protects resources and provides cleaner architecture.
•Server selection affects performance — SRTT-based selection prefers faster servers, improving resolution latency.
•Iterative + recursive complement each other — Clients see recursive simplicity; servers communicate iteratively for scalability.

What's next:

Page Complete

2 / 5