Local DNS Servers

When you type www.google.com into your browser, your computer doesn't directly contact root servers, TLD servers, or Google's authoritative servers. Instead, it sends a single query to a local DNS server—a recursive resolver that does all the hierarchical traversal work on your behalf.

Local DNS servers are the workhorses of DNS. While authoritative servers merely hold data, resolvers actively navigate the DNS hierarchy, cache results, and optimize performance. They're the layer that makes DNS feel instantaneous, even though resolution might require querying servers on three continents. Understanding resolvers means understanding how DNS actually works for end users.

A recursive resolver (also called a recursive DNS server, caching resolver, or simply "local DNS server") is a DNS server that accepts queries from clients and performs the full resolution process on their behalf.

The 'recursive' in recursive resolver:

The term 'recursive' refers to how the resolver handles queries:

1. Client asks resolver: "What's the IP for www.example.com?"
2. Resolver performs all work: Queries root, TLD, authoritative as needed
3. Resolver returns final answer: Client receives the IP address

The client doesn't need to know about root servers or the DNS hierarchy—it just asks and receives. The resolver recursively resolves by following referrals until it obtains the final answer.

Key differences from authoritative servers:

DNS resolution involves two types of resolvers that work together:

Stub Resolver (Client-Side)

Every operating system includes a stub resolver—a minimal DNS client library that:

• Reads system DNS configuration (e.g., /etc/resolv.conf on Linux, DHCP-provided settings on Windows)
• Formulates DNS queries for applications
• Sends queries to configured recursive resolvers
• Maintains a small local cache (OS-level)
• Returns answers to applications

The stub resolver doesn't traverse the DNS hierarchy—it simply forwards to a configured resolver and waits for answers. It's "stub" because it only handles the first hop.

Full Recursive Resolver (Network-Side)

Full resolvers perform the actual resolution work:

• Receive queries from stub resolvers
• Traverse the DNS hierarchy (root → TLD → authoritative)
• Maintain large caches for performance
• Handle thousands to millions of queries per second
• Implement security features (DNSSEC validation, filtering)
• Often deployed at ISP, enterprise, or public DNS service level

The resolution flow:

[Application] → [Stub Resolver (OS)] → [Full Resolver (Network)] → [DNS Hierarchy]
     |                    |                      |                      |
   makes              forwards              recursively              authoritative
   request            to resolver            resolves                  answers

Caching is the recursive resolver's superpower. Without caching, every DNS query would require traversing the hierarchy—three to six round-trips for each resolution. With caching, most queries resolve in one hop or less.

What gets cached:

Resolvers cache much more than just final answers:

How TTL works:

Every cached record has a TTL (Time-To-Live) countdown:

1. Authoritative server sets TTL: e.g., www.example.com 300 IN A 93.184.216.34
2. Resolver caches with TTL: Starts a 300-second countdown
3. TTL decrements: Each second, the cached TTL decreases
4. Expiration: At TTL=0, the record is dropped from cache
5. Next query: Must re-resolve from authoritative

TTL behavior across the chain:

Cache efficiency metrics:

Well-configured resolvers achieve high cache hit rates:

Cache warming:

Some resolvers implement cache warming or prefetching:

• Before records expire, proactively re-resolve while serving stale data
• Ensures cache is always fresh for popular domains
• Reduces latency spikes when popular records expire

Users have choices about which recursive resolver handles their DNS. The two main options represent different tradeoffs:

ISP-Provided Resolvers

By default, most Internet connections use the ISP's resolvers (assigned via DHCP):

Advantages:

• Near network proximity (low latency)
• CDN optimization (CDNs use resolver location for geo-routing)
• No additional configuration needed
• ISP has support responsibility

Disadvantages:

• May be subject to censorship or content filtering
• Logging policies may lack transparency
• May have slower update of cached records
• Sometimes used for ad injection or analytics
• May not support modern security features (DoH/DoT)

Public DNS advantages:

• Transparency: Published privacy policies and audit reports
• Performance: Global Anycast networks, optimized infrastructure
• Security features: DNSSEC validation, DoH/DoT, malware filtering (some)
• Reliability: High availability SLAs (99.99%+ uptime)
• Bypass censorship: May avoid ISP-level content blocking

CDN and geo-routing considerations:

Content Delivery Networks (CDNs) use the resolver's IP address to determine where to direct users. When you use a public DNS:

• CDN sees query from Google/Cloudflare's resolver, not your ISP
• May route you to a different (sometimes suboptimal) CDN edge location
• EDNS Client Subnet (ECS) mitigates this: resolver forwards client subnet to authoritatives

Both Google DNS and Cloudflare support ECS for supported CDNs, minimizing geo-routing impact.

Modern recursive resolvers implement multiple security mechanisms to protect users from attacks and ensure query/response integrity.

DNSSEC Validation

DNSSEC-validating resolvers verify cryptographic signatures on DNS responses:

1. Resolver receives signed response: Includes RRSIG, DNSKEY, DS records
2. Validates signature chain: From root trust anchor through TLD to domain
3. Verified responses: Marked as secure (AD flag set)
4. Failed validation: Returns SERVFAIL; protects users from forged data

DNSSEC prevents cache poisoning and man-in-the-middle attacks on DNS.

DNS over HTTPS (DoH) and DNS over TLS (DoT)

Traditional DNS uses unencrypted UDP/TCP on port 53—visible to anyone intercepting network traffic. DoH and DoT provide encryption:

DoH vs. DoT tradeoffs:

Additional resolver security:

Many organizations deploy their own recursive resolvers rather than relying on ISP or public DNS. This provides control, security, and integration with internal DNS.

Common deployment scenarios:

1. Enterprise Internal Resolver

• Resolves internal domains (corp.example.com) from internal authoritative servers
• Forwards external queries to upstream resolvers or resolves directly
• Enforces security policies (block known malicious domains)
• Provides DNS-level analytics and logging
• Integrates with Active Directory (in Windows environments)

Split-horizon DNS:

Enterprises often implement split-horizon (split-brain) DNS:

• Internal resolver returns internal IPs for internal queries (e.g., app.example.com → 10.0.1.50)
• External resolver returns public IPs for the same names (e.g., app.example.com → 203.0.113.50)
• Same domain name maps to different addresses based on query source

This enables internal users to access services via private network while external users use public addresses.

Forwarding vs. recursion:

Resolvers can operate in different modes:

Understanding resolver behavior is essential for troubleshooting DNS issues. Here are key diagnostic techniques and common problems.

Essential DNS diagnostic tools:

Common resolver issues and solutions:

The +trace diagnostic:

The dig +trace command is invaluable for debugging. It performs iterative resolution from root, showing each referral: