Name Resolution

When you type www.example.com into your browser and press Enter, a remarkable distributed computation begins. Within milliseconds, your computer must discover the IP address of a server that could be anywhere on Earth—and it accomplishes this through a process called name resolution.

Name resolution is the core function of DNS—the mechanism by which human-readable domain names are translated into machine-routable IP addresses. This process involves multiple servers, sophisticated caching strategies, and a carefully designed query protocol that handles billions of requests daily.

Understanding name resolution is essential for network engineers, system administrators, and developers alike. It explains why websites sometimes "can't be found," how DNS propagation works, and why changing a domain's IP address isn't instantaneous.

Name resolution is the process of determining the IP address (or addresses) associated with a given domain name. This concept encompasses several related ideas:

Forward Resolution: The most common form of DNS resolution, where a domain name is translated into an IP address:

• www.google.com → 142.250.185.68
• api.github.com → 20.26.156.215

Reverse Resolution: The opposite process, translating an IP address back to a domain name:

• 8.8.8.8 → dns.google
• 1.1.1.1 → one.one.one.one

Reverse resolution uses a special domain hierarchy under in-addr.arpa (for IPv4) and ip6.arpa (for IPv6).

The Resolution Chain:

Name resolution is rarely a single query-response pair. Instead, it's typically a chain of queries involving multiple servers, each contributing partial knowledge until the complete answer is assembled.

Why Resolution is Non-Trivial:

A naive approach might suggest a single, central database mapping all domain names to IP addresses. However, this approach fails at internet scale for several reasons:

1. Volume: Billions of DNS queries occur daily—no single server could handle this load
2. Latency: A central server (even if powerful enough) would create unacceptable network latency for distant users
3. Availability: A single point of failure for all DNS is unacceptable risk
4. Administration: Different organizations manage different domains—centralized control is impractical
5. Updates: Changes must propagate quickly without requiring global coordination

The solution is a distributed, hierarchical system where resolution involves multiple specialized servers, each responsible for a portion of the namespace.

The name resolution process involves several distinct components, each playing a specific role:

1. Stub Resolver (DNS Client)

The stub resolver is the DNS client software built into your operating system. When an application needs to resolve a domain name, it calls the stub resolver (typically through functions like getaddrinfo() or gethostbyname()).

Stub resolver characteristics:

• Runs on the end-user device (computer, phone, IoT device)
• Maintains a local cache of recent resolutions
• Knows the address of one or more recursive resolvers
• Sends queries to recursive resolvers and returns answers to applications
• Performs minimal processing—delegates most work to recursive resolvers

2. Recursive Resolver (DNS Recursor)

The recursive resolver is the workhorse of DNS resolution. It accepts queries from stub resolvers and does the actual work of traversing the DNS hierarchy to find answers.

Recursive resolver characteristics:

• Typically operated by ISPs, organizations, or public DNS providers (Google, Cloudflare, Quad9)
• Handles the complexity of walking the DNS tree
• Maintains large caches to reduce query volume
• May implement security features (DNSSEC validation, malware filtering)
• Serves thousands to millions of clients

3. Authoritative Name Servers

Authoritative servers are the ultimate source of truth for DNS records. They hold the actual data for their zones and respond definitively to queries about names in those zones.

Authoritative server types:

• Root servers: Answer queries about top-level domains (TLDs)
• TLD servers: Answer queries about domains within a TLD (e.g., all .com domains)
• Domain authoritative servers: Answer queries about specific domains (e.g., example.com)

Let's trace the complete resolution of www.engineering.example.com from start to finish, examining every step in detail:

Step 1: Application Request

A user types the URL into their browser. The browser's networking code needs to establish a TCP connection to the web server, which requires an IP address.

Browser: "I need IP address for www.engineering.example.com"

Step 2: Stub Resolver Cache Check

The stub resolver first checks its local cache. If this domain was resolved recently and the cached answer hasn't expired (TTL not exceeded), the cached IP is returned immediately—no network traffic required.

Stub Resolver: Check local cache... Cache miss.

Step 3: Query to Recursive Resolver

The stub resolver sends a query to its configured recursive resolver (e.g., ISP's DNS or public DNS like 8.8.8.8).

Query: Type=A, Name=www.engineering.example.com
From: Client → Recursive Resolver

Step 4: Recursive Resolver Cache Check

The recursive resolver checks its own cache. Since it serves many clients, there's a good chance someone recently queried this or a related domain.

Recursive Resolver: Check cache... No exact match.
Recursive Resolver: Check cache for 'engineering.example.com' NS records... Miss.
Recursive Resolver: Check cache for 'example.com' NS records... Miss.
Recursive Resolver: Check cache for 'com' NS records... Hit! (TLD info cached)

Note: Recursive resolvers cache not just final answers but also intermediate information (NS records for various delegations). This allows them to skip earlier steps in subsequent queries.

Step 5: Query to Root Servers (if needed)

If no cached information exists, the recursive resolver starts at the root. It has a built-in list of root server addresses (the "root hints file").

Recursive Resolver → Root Server:
  Query: "Who handles the .com TLD?"

Root Server Response:
  "I don't know www.engineering.example.com, but .com is handled by
   these TLD servers: a.gtld-servers.net (192.5.6.30), ..."

Step 6: Query to TLD Servers

The recursive resolver queries a .com TLD server:

Recursive Resolver → .com TLD Server:
  Query: "Who handles example.com?"

TLD Server Response:
  "I don't know www.engineering.example.com, but example.com is handled by
   these authoritative servers: ns1.example.com (93.184.216.34), ..."

Step 7: Query to Authoritative Servers

The recursive resolver queries the authoritative server for example.com:

Recursive Resolver → example.com Authoritative Server:
  Query: "What is the IP address for www.engineering.example.com?"

Authoritative Server Response (Type A):
  "www.engineering.example.com has IP address 203.0.113.50"
  "TTL: 3600 seconds (1 hour)"

Step 8: Response Caching and Return

The recursive resolver caches the answer (and all intermediate NS records) according to their TTLs, then returns the answer to the stub resolver:

Recursive Resolver → Stub Resolver:
  Answer: www.engineering.example.com = 203.0.113.50
  TTL: 3600 seconds

Stub Resolver: Cache this answer, return to application.

Application: Connect to 203.0.113.50:443

DNS supports two query modes, each with distinct behaviors and use cases:

Recursive Query:

In a recursive query, the client asks the server to provide the complete answer. If the server doesn't have the answer, it must query other servers on the client's behalf and return the final result.

• Who uses it: Stub resolvers querying recursive resolvers
• Server obligation: Must return either the answer or an error
• Processing burden: Server does all the work
• Typical use: Client devices with limited capability

Iterative Query:

In an iterative query, the client asks the server for its best answer. If the server doesn't have the definitive answer, it returns a referral—the address of another server that might know better.

• Who uses it: Recursive resolvers querying authoritative servers
• Server obligation: Returns answer if known, otherwise returns referral
• Processing burden: Client (recursive resolver) does the walking
• Typical use: Server-to-server communication

The Hybrid Reality:

In practice, DNS resolution combines both modes:

1. Stub resolver → Recursive resolver: Recursive query (client expects full answer)
2. Recursive resolver → Authoritative servers: Iterative queries (resolver follows referrals)

This hybrid approach optimizes the system: lightweight clients make simple recursive requests, while powerful recursive resolvers handle the complexity of iterating through the DNS hierarchy.

Caching is fundamental to DNS's ability to handle billions of queries daily. Every component in the resolution chain maintains caches that dramatically reduce query volume and latency.

Caching at Multiple Levels:

1. Browser Cache: Modern browsers maintain their own DNS caches, independent of the OS.

• Chrome: chrome://net-internals/#dns
• Firefox: about:networking#dns
• Typical TTL: Minutes (often ignores actual TTL, uses shorter values)

2. Operating System Cache: The OS stub resolver caches resolutions for all applications.

• Windows: ipconfig /displaydns
• macOS/Linux: Varies by resolver daemon (systemd-resolved, dnsmasq, etc.)
• TTL: As specified by DNS responses

3. Recursive Resolver Cache: Large cache shared across all clients of that resolver.

• May serve millions of users
• Caches both answers and intermediate NS records
• TTL: As specified, often with minimum/maximum bounds

4. Authoritative Server Response Cache: Some authoritative servers cache zone data in memory for fast response.

Cache Hit Rates:

Large recursive resolvers often achieve cache hit rates of 80-95%. This means only 5-20% of queries actually require traversing the DNS hierarchy. The implications are significant:

1. Reduced Latency: Cached answers return in milliseconds
2. Reduced Load: Root and TLD servers handle far fewer queries
3. Improved Resilience: Cached data remains available during brief outages
4. Scalability: The system handles exponential growth efficiently

Negative Caching:

DNS also caches negative results—when a domain doesn't exist (NXDOMAIN response). This prevents repeated queries for typos or non-existent domains.

• Negative cache TTL is specified by the SOA record's minimum TTL field
• Typically 60 seconds to 1 hour
• Important for protecting servers from query floods to bad domains

DNS queries and responses follow a well-defined protocol format, specified in RFC 1035 and extended by numerous subsequent RFCs.

Transport Protocols:

UDP (Port 53):

• Primary transport for DNS
• Fast, connectionless
• Single packet for query, single packet for response (when possible)
• 512 byte limit traditionally (extended by EDNS0)
• Used for most queries

TCP (Port 53):

• Used when responses exceed 512 bytes (or EDNS0 negotiated size)
• Required for zone transfers (AXFR/IXFR)
• Connection overhead but unlimited response size
• Increasingly used for reliability

Query Types:

DNS supports numerous record types, each serving different purposes:

EDNS0 (Extension Mechanisms for DNS):

EDNS0 (RFC 6891) extends DNS capabilities beyond the original specification:

• Larger UDP responses (up to 4096 bytes or more)
• DNSSEC support (additional flags and record types)
• Client subnet information (for CDN optimization)
• Cookie support (for security)

Not every DNS resolution succeeds. Understanding failure modes is crucial for troubleshooting:

Common Resolution Errors:

Troubleshooting Resolution Issues:

Timeout/No Response:

• Network connectivity issues
• Firewall blocking DNS (port 53)
• Resolver server down
• Packet loss in transit

SERVFAIL:

• DNSSEC validation failure
• Authoritative server unreachable
• Zone misconfiguration
• Lame delegation (NS points to non-authoritative server)

NXDOMAIN:

• Domain doesn't exist (typo?)
• Domain registration expired
• Zone not properly delegated

Wrong Answer/Unexpected IP:

• DNS hijacking/spoofing
• Stale cache (wait for TTL expiry)
• Split-horizon DNS (different answers for internal/external)