Introduction to DNS

3. DNS resolvers

A DNS resolver is any component (software or hardware) responsible for translating a human-friendly domain name (like example.com) into the IP address that the computer needs to connect to (such as 93.184.216.34).

When you type a website address into your browser or click a link, your system relies on DNS resolvers to figure out the correct IP address. There are several types of DNS resolvers, each serving different roles in the DNS lookup process.

The DNS Lookup Process in Brief

Before diving into the types of DNS resolvers, it helps to have a high-level overview of the DNS lookup process:

1. You request a domain name (e.g., example.com) from your computer or device.
2. Your computer’s resolver (or stub resolver) sends the request to a DNS recursive resolver (often your ISP’s or a public DNS like Google’s 8.8.8.8).
3. The recursive resolver checks if it already has the domain name’s IP address in its cache. If so, it returns it immediately.
4. If not, the recursive resolver queries the root DNS servers, then the TLD (Top-Level Domain) DNS servers, then the authoritative DNS server for the domain, following DNS hierarchy.
5. Once the IP address is found, the resolver returns it to your computer. Your computer can then contact the web server at that IP.

1. Stub Resolver

A stub resolver is the minimal DNS client software running on your device (laptop, smartphone, IoT gadget, etc.) that starts the DNS lookup process. It typically does not perform the full DNS query process by itself.

How It Works

• The stub resolver knows one or more DNS servers to send queries to. These DNS servers are often configured automatically (for example, via DHCP on your home router) or manually by users (e.g., configuring 8.8.8.8 for Google DNS).
• When your device needs to resolve a domain name, the stub resolver sends a request to the configured DNS server and waits for the response.
• The stub resolver takes the response (the IP address or an error) and hands it back to the application (like a web browser).

Example

• On Windows or macOS, you can see your DNS server addresses in your network settings. These addresses often point to your router (which might act as a basic DNS forwarder) or directly to an ISP-provided DNS server.
• If you have manually configured 8.8.8.8 (Google Public DNS) or 1.1.1.1 (Cloudflare DNS), your computer’s stub resolver sends all DNS queries to Google or Cloudflare, respectively.

2. Recursive Resolver

A recursive resolver is a DNS server that actively performs the DNS query process on behalf of the client. It hunts down the IP address by querying multiple DNS servers until it gets the final answer.

How It Works

1. The recursive resolver receives a request from a stub resolver (or another forwarder).
2. It first checks its local cache to see if the requested domain’s IP address is stored there.
   • If found, it returns the cached answer immediately.
3. If the record is not cached, the resolver queries the root DNS servers to learn which TLD server (e.g., .com, .org) to query next.
4. It then queries the relevant TLD server to find the authoritative DNS server for the specific domain.
5. Finally, it queries the authoritative server to obtain the required DNS records (e.g., the A record for IPv4).
6. The resolved IP is cached for future requests and returned to the stub resolver.

Example

• ISP DNS Resolver: Most internet service providers run their own recursive DNS resolvers that their customers use by default.
• Public DNS Resolver: Google Public DNS (8.8.8.8), Cloudflare DNS (1.1.1.1), and OpenDNS (208.67.222.222) are common public recursive resolvers.

3. Caching-Only Resolver

A caching-only resolver is a type of DNS server whose primary function is to cache DNS query results and reuse them to speed up subsequent lookups. It does not host any DNS zones (i.e., it is not authoritative for any domain) and typically performs recursive lookups on behalf of clients.

How It Works

• Like a recursive resolver, a caching-only resolver forwards queries to other DNS servers if the record is not already in its cache.
• Once it obtains the result, it stores (caches) the DNS records for the duration specified by their TTL (Time to Live).
• Subsequent queries for the same domain within the TTL period are served faster from the cache, reducing the need for external lookups.

Example

• Many home routers or DNS forwarders act as caching-only resolvers. Once a family member’s device visits example.com, the router caches the IP for that domain. If another device requests example.com soon after, it is resolved almost instantly from the router’s cache.

4. Forwarder

A forwarder is a DNS server that forwards all queries (or queries that it cannot resolve locally) to another DNS server instead of performing the complete recursive resolution process itself.

How It Works

• A DNS server is configured to send queries to an upstream DNS server, often a well-known public DNS or an ISP DNS.
• The forwarder may still maintain a local cache to speed up DNS resolution for repeated queries.
• This setup is common in corporate networks to manage and log DNS queries centrally or apply custom policies (e.g., content filtering).

Example

• A small business might have a local DNS server that forwards any external domain queries to their ISP’s DNS servers or Google DNS. This helps centralize DNS settings and possibly implement local domain resolutions (like intranet.local) without handling the complexity of a full recursive resolver setup.

5. Iterative (Non-Recursive) Resolver

Sometimes called a non-recursive resolver, an iterative resolver typically gives back partial results or referrals, instructing the client to continue the resolution process on its own.

How It Works

• If a client asks this resolver for a record, the resolver either:
  • Returns the answer if it is authoritative or has it cached, or
  • Returns a referral with the address of another DNS server (for instance, the root or TLD server), prompting the client to “try there next.”

This type is less common for end-user devices; it is often used by authoritative DNS servers to direct queries up or down the DNS hierarchy.

Example

• An authoritative DNS server for example.com typically returns referrals for subdomains it does not know. If you ask it about sub.example.com but that subdomain is handled by a different name server, it might respond with the details of that other name server rather than performing the recursion on your behalf.

Visualizing the DNS Resolution Chain

Below is a simplified chart showing the typical path of a DNS query:

User's Device (Stub Resolver)
     |
     v
Recursive Resolver (Often ISP/ Public)
     |
     v
  Root Server
     |
     v
 TLD Server (.com, .net, etc.)
     |
     v
 Authoritative Server (example.com)
     |
     v
   IP Address

• Stub resolver: Passes the domain name request to the recursive resolver.
• Recursive resolver: Takes on the hard work of querying each layer (root, TLD, authoritative) if it doesn’t have the answer cached.
• Caching: Each resolver may cache responses to speed up future queries.

Putting It All Together

1. Stub Resolver on your device:

   • Minimal functionality—just sends the query to a DNS server.

2. Recursive Resolver (may also be a Caching-Only Resolver):

   • Receives queries from stub resolvers.
   • Looks up (recursively) the chain of DNS servers if not cached.
   • Caches the response for future requests.

3. Forwarder:

   • A DNS server configured to pass queries on to another resolver rather than doing the full lookup.
   • Can also cache responses.

4. Iterative (Non-Recursive) Resolver:

   • Responds with direct answers if known or references to other DNS servers (referrals), but doesn’t do recursion.

Real-World Example Scenario

1. Your Laptop (Stub Resolver) is set to use 8.8.8.8 (Google DNS).
2. You type www.example.com into your browser.
3. The stub resolver on your laptop sends the DNS query to 8.8.8.8 (a Public Recursive Resolver).
4. Google DNS checks its cache:
   • If www.example.com is cached, it returns the IP right away.
   • If not, it queries the root server, then .com TLD server, then the example.com authoritative server in turn.
5. Once found, the IP address is cached in Google’s DNS servers and returned to your laptop’s stub resolver.
6. Your laptop connects to the returned IP address, and the website loads.