DNS Resolver

What is a DNS Resolver?

A DNS resolver (also called a recursive resolver or recursive DNS server) is a server that receives DNS queries from client devices and performs the work of tracking down the IP address for a domain name. Resolvers act as intermediaries between clients and the DNS hierarchy, handling the recursion through root, TLD, and authoritative nameservers.

How DNS Resolvers Work

The Resolution Process

When you type "example.com" in your browser:

1. Client → Resolver: "What's the IP for example.com?"

2. Resolver checks cache
   → Cache hit: Return cached result
   → Cache miss: Begin recursion

3. Resolver → Root Server: "Where's .com?"
   Root → Resolver: "Ask these .com nameservers"

4. Resolver → .com TLD: "Where's example.com?"
   .com → Resolver: "Ask these nameservers"

5. Resolver → Authoritative NS: "What's example.com's IP?"
   Auth NS → Resolver: "203.0.113.50"

6. Resolver → Client: "203.0.113.50"
   (Also caches result based on TTL)

Recursive vs Iterative Queries

Client: "Give me the final answer for example.com"
Resolver: "Here's the IP: 203.0.113.50"
        (Resolver does all the work)

Resolver: "What's example.com?"
Root: "I don't know, ask .com servers"
Resolver: "What's example.com?"
.com: "I don't know, ask ns1.example.com"
Resolver: "What's example.com?"
ns1: "203.0.113.50"

Types of Resolvers

Stub Resolver

Built into operating systems and applications:

• Forwards queries to configured DNS servers
• Minimal logic
• Doesn't perform recursion

Recursive Resolver

Full-featured servers that perform complete DNS resolution:

• Caches results
• Follows referrals
• Implements security features

Forwarding Resolver

Forwards queries to another resolver instead of performing recursion:

• Common in corporate networks
• Central policy enforcement
• Reduced external queries

Client → Corporate Resolver (forwarding) → ISP Resolver (recursive) → Internet

Popular Public Resolvers

Changing Your Resolver

Control Panel → Network → Adapter Settings
→ Properties → IPv4 → Use these DNS servers:
   Preferred: 1.1.1.1
   Alternate: 8.8.8.8

System Preferences → Network → Advanced → DNS
→ Add: 1.1.1.1, 8.8.8.8

nameserver 1.1.1.1
nameserver 8.8.8.8

Resolver Features

Caching

Resolvers cache DNS responses based on TTL:

First query: example.com
→ Full recursion (50ms)
→ Cached for 300s (TTL)

Subsequent queries: example.com
→ Cache hit (1ms)
→ Served until TTL expires

Negative Caching

Resolvers also cache negative responses (NXDOMAIN):

Query: nonexistent.example.com
Response: NXDOMAIN
Cached: Based on SOA minimum TTL

This prevents repeated queries for non-existent domains.

Query Minimization

Modern resolvers minimize information disclosure:

Query to .com: "What's www.blog.example.com?"
→ Exposes full subdomain structure

Query to .com: "What's example.com?"
Query to example.com NS: "What's blog.example.com?"
Query to blog.example.com NS: "What's www.blog.example.com?"
→ Reveals only necessary information at each level

DNSSEC Validation

Security-aware resolvers validate DNSSEC signatures:

Query: example.com (DNSSEC-signed)
→ Resolver validates signatures
→ Returns AD (Authentic Data) flag if valid
→ Returns SERVFAIL if signatures invalid

Resolver Security Features

DNS over HTTPS (DoH)

Encrypts DNS queries over HTTPS:

Traditional DNS:
Client → Resolver (UDP port 53, plaintext)

DNS over HTTPS:
Client → Resolver (TCP port 443, encrypted)

DNS over TLS (DoT)

Encrypts DNS queries over TLS:

Client → Resolver (TCP port 853, encrypted)

Malware/Phishing Filtering

Some resolvers block known malicious domains:

Rate Limiting

Protects against DNS amplification attacks:

If source IP sends > threshold queries/second:
→ Temporarily rate limit or block

Checking Your Current Resolver

ipconfig /all | findstr "DNS Servers"

cat /etc/resolv.conf

dig example.com
# Look at "SERVER:" in output

Resolver Performance

Latency Matters

Resolver response time impacts web performance:

Anycast Routing

Major resolvers use anycast for low latency:

1.1.1.1 anycast IP
→ Routed to nearest Cloudflare datacenter
→ New York query → New York datacenter
→ London query → London datacenter
→ Result: Global low-latency resolution

Measuring Resolver Performance

# Tests multiple resolvers with your actual query patterns
namebench

# Test Cloudflare
time dig @1.1.1.1 example.com

# Test Google
time dig @8.8.8.8 example.com

# Test ISP (current)
time dig example.com

Common Resolver Issues

DNS Poisoning

Attackers inject false records into resolver cache:

• Use resolvers with DNSSEC validation
• Enable source port randomization
• Use DoH/DoT to prevent man-in-the-middle attacks

Resolver Hijacking

ISPs or malware redirect DNS queries:

• Change to public resolver (1.1.1.1, 8.8.8.8)
• Use DoH/DoT to prevent ISP interference
• Check for malware

Stale Cache

Resolver caches outdated records:

• Wait for TTL to expire
• Use different resolver temporarily
• Flush local cache

Resolver Blocking

Some networks block external resolvers:

• Use DNS over HTTPS (harder to block)
• Use resolver's DoH endpoint

Configuring a Local Resolver

Using Unbound

# Install Unbound (Linux)
sudo apt install unbound

# Basic config (/etc/unbound/unbound.conf)
server:
  interface: 127.0.0.1
  do-ip4: yes
  do-udp: yes
  do-tcp: yes

  # Enable DNSSEC
  auto-trust-anchor-file: "/var/lib/unbound/root.key"

  # Privacy (query minimization)
  qname-minimisation: yes

# Start service
sudo systemctl start unbound
sudo systemctl enable unbound

Using Pi-hole

Network-wide ad-blocking DNS resolver:

# Install Pi-hole
curl -sSL https://install.pi-hole.net | bash

# Configure devices to use Pi-hole as resolver
# Set router DHCP to provide Pi-hole IP as DNS

Best Practices

1. Use reputable public resolvers: Cloudflare, Google, or Quad9 for reliability

2. Enable DoH/DoT: Encrypt queries for privacy and security

3. Consider resolver features: Choose based on privacy, speed, or security needs

4. Monitor resolver performance: Test latency periodically

5. Have backup resolvers: Configure secondary DNS for redundancy

6. Use DNSSEC-validating resolvers: Protect against cache poisoning

7. Understand your resolver's policies: Some filter content, some log queries

8. Test after changes: Verify DNS resolution works correctly

9. Document resolver choice: Note why you chose a particular resolver

10. Update resolv.conf carefully: Incorrect configuration breaks DNS entirely

Resolver vs Authoritative Nameserver

DNS resolvers are the workhorses of the DNS system—choosing a fast, secure, privacy-respecting resolver significantly impacts your browsing experience and online security.