Recursive Resolution

When you type www.google.com into your browser, something remarkable happens behind the scenes. Within milliseconds, your device translates that human-readable name into an IP address like 142.250.80.4—but your device doesn't actually perform this translation itself. Instead, it delegates this complex task to a specialized system using a process called recursive resolution.

Understanding recursive resolution is fundamental to grasping how DNS actually works in practice. It's the mechanism that shields end-user applications from the complexity of the distributed DNS hierarchy, providing a simple interface: "Give me the IP address for this name, and don't come back until you have it."

Recursive resolution is a DNS query mode where the queried server takes full responsibility for obtaining the complete answer. When a client sends a recursive query, it's essentially saying: "I need the IP address for this domain name. You figure out how to get it, follow all the necessary steps, and return the final answer to me."

This contrasts sharply with iterative resolution (covered in the next page), where each server simply provides the best information it has and directs the client to ask elsewhere for more details.

The core promise of recursive resolution:

To appreciate recursive resolution, we must understand the problem it solves. The DNS namespace is hierarchical and distributed:

• 13 root server clusters sit at the top of the hierarchy
• Over 1,500 TLD zones (like .com, .org, .uk) each managed by different operators
• Hundreds of millions of authoritative zones hosting individual domain records

If end-user devices had to navigate this hierarchy themselves for every DNS query, several problems would emerge:

The architectural insight:

Recursive resolution implements a proxy pattern at the DNS layer. Instead of every client implementing complex resolution logic, we designate specialized servers—recursive resolvers or caching resolvers—to handle this complexity on behalf of many clients. This centralizes the complexity, improves efficiency through shared caching, and dramatically reduces the load on the authoritative DNS infrastructure.

Real-world scale perspective:

Consider that Google's public DNS resolver (8.8.8.8) handles over 1 trillion queries per day. Without recursive resolution and the caching it enables, every client would need to perform 3-4 round trips across the global DNS hierarchy for each of those trillion queries—an impossible load for the root and TLD infrastructure.

Let's trace the complete journey of a recursive DNS query. When a user's browser needs to resolve www.example.com, the following sequence occurs:

Phase 1: Client Query Initiation

The client (typically the operating system's stub resolver) creates a DNS query packet with:

• Query name: www.example.com
• Query type: A (IPv4 address) or AAAA (IPv6 address)
• Query class: IN (Internet)
• Flags: RD=1 (Recursion Desired)

This packet is sent to the configured recursive resolver (often obtained via DHCP or manually configured).

Phase 2: Resolver Cache Check

Before contacting any external servers, the recursive resolver checks its cache:

1. Exact match: Does the cache have the A/AAAA record for www.example.com? If yes and TTL hasn't expired, return immediately.
2. NS delegation check: Does the cache have NS records for example.com? If yes, skip directly to the authoritative servers.
3. Parent zone check: Does the cache have NS records for .com? If yes, skip root servers.

This cache hierarchy means most queries never reach the root servers. Studies show over 99% of root server queries could be eliminated with perfect caching.

Phase 3: Iterative Descent

If the cache misses, the resolver performs iterative queries (note: the resolver uses iterative queries to implement the client's recursive request):

1. Query root servers: The resolver has a pre-configured list of root server IP addresses (the "root hints"). It queries one of these for www.example.com.

2. Process referral: The root server responds with a referral—NS records for .com TLD servers plus their IP addresses (in the "Additional" section as "glue records").

3. Query TLD servers: The resolver now queries a .com TLD server for www.example.com.

4. Process referral: The TLD server responds with NS records for example.com's authoritative servers.

5. Query authoritative servers: The resolver queries example.com's authoritative server for www.example.com.

6. Receive answer: The authoritative server returns the actual A/AAAA record.

Phase 4: Response and Caching

Once the resolver obtains the answer:

1. Cache all results: The resolver caches not just the final A record, but also all intermediate NS records and referrals, each with their respective TTLs.
2. Construct response: The resolver builds a DNS response packet with the answer.
3. Set flags: The response includes RA=1 (Recursion Available) to confirm the server performed recursion.
4. Return to client: The complete answer is returned in a single response packet.

From the client's perspective, this entire multi-step process appears as one simple query/response cycle lasting perhaps 50-150ms (or <1ms if cached).

Understanding the low-level mechanics of recursive resolution helps diagnose issues and appreciate the engineering involved.

Query ID Tracking

The recursive resolver manages multiple outstanding queries simultaneously. Each query receives a unique 16-bit Query ID. When responses arrive, the resolver matches them to pending requests using this ID. Modern resolvers also randomize source ports to prevent spoofing attacks.

Timeout and Retry Logic

Network issues are handled transparently:

Glue Records and the Bootstrap Problem

A subtle challenge in DNS: To query ns1.example.com, you need the IP address of ns1.example.com. This circular dependency is resolved using glue records—IP addresses included in the parent zone's referral response.

; In the .com zone, when delegating example.com:
example.com.    NS    ns1.example.com.
example.com.    NS    ns2.example.com.
ns1.example.com. A    192.0.2.1      ; Glue record
ns2.example.com. A    192.0.2.2      ; Glue record

The resolver receives NS records and their IP addresses in the same response, avoiding the chicken-and-egg problem.

CNAME Chasing

When the resolver encounters a CNAME (Canonical Name) record, it must continue resolution for the target name:

www.example.com.  CNAME  webserver.cdn.example.net.
webserver.cdn.example.net.  A  203.0.113.50

The resolver automatically follows CNAME chains (up to a limit, typically 8-16 levels to prevent infinite loops) and returns the final A/AAAA record along with all intermediate CNAME records.

Negative Caching

Recursive resolvers also cache negative responses:

• NXDOMAIN: The domain does not exist. Cached based on the SOA record's minimum TTL field (negative cache TTL).
• NODATA: The domain exists but has no records of the requested type. Also cached using SOA TTL.

Negative caching prevents repeated queries for non-existent domains, which is important for reducing unnecessary load and improving response times for follow-up queries.

Not all recursive resolvers are created equal. Understanding the different types helps you make informed choices about DNS configuration:

Recursive resolution introduces security considerations that network engineers must understand:

Open Resolver Risk

A recursive resolver configured to accept queries from anyone on the Internet is called an open resolver. This creates two serious problems:

Mitigation: Restrict Recursion

Recursive resolvers should be configured to accept recursive queries only from authorized clients:

# BIND configuration example
acl "trusted-clients" {
    192.168.0.0/16;     # Internal network
    10.0.0.0/8;          # Private range
    localhost;
};

options {
    recursion yes;
    allow-recursion { trusted-clients; };
    allow-query { trusted-clients; };
};

DNS Spoofing and Cache Poisoning

Before DNSSEC, attackers could race to provide fake responses to recursive resolvers:

1. Attacker predicts or observes a query being sent
2. Attacker sends forged response before legitimate response arrives
3. If query ID and other parameters match, resolver accepts fake response
4. Fake record is cached and served to all clients

Modern mitigations include:

• Query ID randomization: Makes prediction harder (16 bits of entropy)
• Source port randomization: Adds ~16 more bits of entropy
• 0x20 encoding: Randomizes case in query name, adding more bits
• DNSSEC validation: Cryptographically verifies response authenticity

Recursive resolver performance directly impacts application latency and user experience. Key optimization strategies include:

Prefetching

Intelligent resolvers can refresh cache entries before they expire:

• Track popular domain queries
• When a cached record reaches 75-90% of its TTL, initiate a background refresh
• Users always get cached responses; never wait for cold queries on popular names

Query Minimization (QNAME Minimization)

Traditional resolvers send the full query name to every server in the chain. Query minimization (RFC 7816) sends only enough information to get the next referral:

This improves privacy (fewer servers see the full query) and can slightly reduce response sizes.

Connection Reuse

Modern resolvers using DNS-over-TLS or DNS-over-HTTPS reuse connections:

• TCP connection reuse: Avoid three-way handshake for each query
• TLS session resumption: Skip full TLS handshake on reconnection
• HTTP/2 multiplexing: Send multiple queries over single connection