Resolver Role — DNS Resolution | OneNoughtOne

0/121

Computer NetworksDNS Resolution

DNS Resolution

LevelIntermediate

Duration60 mins

TopicDNS Resolution

4 / 5

Resolver Role

The Unsung Hero of DNS

Every DNS query you make—every website visit, email sent, app connection—flows through a DNS resolver. Yet most users never think about which resolver they use or what that resolver does beyond basic name-to-IP translation. The resolver is far more than a lookup service. It's a caching engine, a security gateway, a privacy boundary, and often a policy enforcement point . The choice of resolver affects your browsing speed, your protection from malicious domains, and who can observe your Internet activity. In this page, we explore the resolver's multifaceted role, examining configuration options, extended services, and the profound implications of resolver selection.

What You Will Learn

By the end of this page, you will understand: (1) The complete set of services a resolver provides, (2) Types of resolvers and their characteristics, (3) How resolvers are configured across different systems, (4) Privacy and security implications of resolver choice, and (5) Advanced resolver features like filtering and DNSSEC validation.

Resolver Responsibilities

A recursive DNS resolver performs many more functions than simply translating names to addresses. Understanding these responsibilities reveals why resolver choice matters. Core Resolution Functions:

Primary Resolver Duties

•Query Processing: Accept client queries, validate format, parse question section
•Cache Management: Store responses with TTL, evict expired entries, handle negative caching
•Iterative Resolution: Navigate DNS hierarchy from root through TLD to authoritative servers
•Response Construction: Assemble answer from cached data or fresh resolution
•Error Handling: Detect failures, retry with alternate servers, return appropriate RCODE

Extended Services: Modern resolvers provide capabilities far beyond basic resolution:

Extended Resolver Services
Service	Description	Value
DNSSEC Validation	Verify cryptographic signatures on responses	Prevents cache poisoning and spoofing
Malware Blocking	Block domains known to host malware	Protects clients from infections
Phishing Protection	Block domains used for credential theft	Reduces phishing success rates
Content Filtering	Block categories of content (adult, gambling, etc.)	Parental controls, workplace policy
Anycast Distribution	Serve from geographically distributed locations	Reduces latency globally
Query Logging	Record what domains clients resolve	Security analysis, compliance (with privacy concerns)
Rate Limiting	Limit query rates per client	Prevents abuse, DDoS mitigation
Split-Horizon	Return different results for internal vs external clients	Internal resource access

The Resolver as Security Control Point

Because all DNS queries flow through the resolver, it's a natural enforcement point for security policies. Blocking malicious domains at the resolver prevents connections before they start—more efficient than detecting malware after download or blocking IPs at the firewall.

Resolver Types

Different environments use different resolver types, each with distinct characteristics: Stub Resolver (Client Resolver) The simplest form—a lightweight component on end-user devices: Implements only the client side of DNS protocol Sends recursive queries, expects complete answers Minimal caching (sometimes none, sometimes OS-level cache) Configured with upstream resolver address Examples: Windows DNS Client service, glibc resolver, systemd-resolved Recursive Resolver (Caching Resolver) The workhorse of DNS infrastructure: Accepts recursive queries from clients Performs iterative resolution through DNS hierarchy Maintains comprehensive cache May provide filtering, logging, security features Examples: BIND, Unbound, PowerDNS Recursor, Knot Resolver

Full Recursive Resolver

•Resolves from root hints (complete independence)
•Maximum control over resolution behavior
•Can apply custom policies at every step
•Higher resource requirements
•Good for: ISPs, enterprises, privacy-focused setups

Forwarding Resolver

•Forwards queries to upstream recursive resolver
•Caches responses locally
•Lower resource usage
•Depends on upstream reliability
•Good for: Home routers, edge caching, local filtering

Authoritative-Only Resolver Some servers only answer authoritatively for configured zones: No recursion for external queries Responds with referrals for non-local zones Often part of enterprise internal DNS Hybrid Configurations Many deployments combine roles: Authoritative for internal zones, forwarding for external Recursive for trusted clients, referral-only for others Local cache + upstream resolver for redundancy

Popular DNS Resolver Software
Software	Type	Key Features	Common Use
BIND 9	Full recursive + authoritative	Industry standard, comprehensive features	ISPs, enterprises, root servers
Unbound	Recursive only	Fast, secure, DNSSEC validation	ISPs, privacy resolvers
PowerDNS Recursor	Recursive only	High performance, Lua scripting	Large-scale deployment
Knot Resolver	Recursive only	Modular, modern design	Research, specialized deployments
dnsmasq	Forwarding + DHCP	Lightweight, integrated services	Home routers, small networks
systemd-resolved	Stub + local cache	Integrated with systemd	Modern Linux desktops
CoreDNS	Modular, plugin-based	Kubernetes DNS, cloud-native	Container orchestration

Resolver Configuration

Resolver configuration varies across operating systems and network environments. Understanding these mechanisms is essential for troubleshooting and customization. Linux Configuration:

/etc/resolv.conf (Traditional Linux)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# Primary nameserver (queried first)
nameserver 8.8.8.8
 
# Secondary nameserver (failover)
nameserver 8.8.4.4
 
# Local resolver (common with systemd-resolved)
nameserver 127.0.0.53
 
# Search domains (appended to short names)
search example.com corp.example.com
 
# Options
options timeout:2 attempts:3 rotate ndots:1
 
# timeout:N  - Wait N seconds for reply
# attempts:N - Try N times before giving up
# rotate     - Round-robin nameservers instead of failover order
# ndots:N    - Names with < N dots get search domain appended

systemd-resolved (Modern Linux): Modern Linux distributions use systemd-resolved, which provides: Local caching stub resolver (127.0.0.53) Per-interface DNS configuration DNSSEC validation DNS-over-TLS support

systemd-resolved Configuration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# /etc/systemd/resolved.conf
[Resolve]
DNS=8.8.8.8 8.8.4.4
FallbackDNS=1.1.1.1 9.9.9.9
Domains=~.
DNSSEC=yes
DNSOverTLS=opportunistic
 
# View current status
$ resolvectl status
 
# Query using resolved
$ resolvectl query www.example.com
 
# Show cache statistics
$ resolvectl statistics

Windows Configuration: Windows manages DNS at the network adapter level: Control Panel \to Network Connections \to Adapter Properties \to IPv4/IPv6 Properties PowerShell/Command Prompt:

Windows DNS Configuration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# View current DNS settings
Get-DnsClientServerAddress
 
# Set DNS servers for an interface
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("8.8.8.8","8.8.4.4")
 
# View DNS cache
Get-DnsClientCache
 
# Clear DNS cache
Clear-DnsClientCache
 
# Test resolution
Resolve-DnsName www.example.com
Resolve-DnsName www.example.com -Server 1.1.1.1

Mobile Devices:

Platform	Default Behavior	Custom DNS Options
iOS	Uses DHCP-provided	Wi-Fi settings, DNS profiles, Private Relay
Android	Uses DHCP-provided	Private DNS (DoT), per-network settings

Enterprise Environments: In enterprise networks, DNS is typically managed centrally: DHCP assigns DNS — DHCP option 6 provides resolver addresses Active Directory DNS — Domain controllers provide internal DNS Split-brain DNS — Internal resolvers for internal names, external for public Group Policy — Centrally managed DNS settings

DNS Configuration Precedence

Be aware of precedence: VPN DNS settings often override system settings. Containers may use different resolvers than the host. Applications may override system resolvers (e.g., browsers with DoH). When troubleshooting, verify which resolver is actually being used for the specific application.

Public vs Private Resolvers

The choice between public resolvers and ISP/private resolvers involves trade-offs in performance, privacy, and features. Major Public Resolvers:

Major Public DNS Resolvers
Provider	IPv4 Address	IPv6 Address	Notable Features
Google Public DNS	8.8.8.8, 8.8.4.4	2001:4860:4860::8888	High performance, ECS support, logging (anonymized after 24h)
Cloudflare DNS	1.1.1.1, 1.0.0.1	2606:4700:4700::1111	Privacy-focused, WARP VPN option, no query logging
Quad9	9.9.9.9, 149.112.112.112	2620:fe::fe	Threat blocking, non-profit, DNSSEC by default
OpenDNS (Cisco)	208.67.222.222	—	Content filtering, enterprise options
Comodo Secure	8.26.56.26	—	Malware blocking
CleanBrowsing	185.228.168.168	—	Family filter, adult content blocking

Public Resolver Advantages

•Often faster than ISP resolvers
•More reliable (better infrastructure)
•Advanced security features (DNSSEC, malware blocking)
•Privacy options (no logging, encrypted DNS)
•Bypass ISP DNS manipulation

Public Resolver Concerns

•Single entity sees all your DNS queries
•May impact CDN optimization (wrong ECS)
•Regulatory concerns in some jurisdictions
•Trust in provider's privacy commitment
•Potential single point of failure

ISP Resolver Characteristics:

Factor	Typical ISP Resolver
Performance	Variable; may be overloaded during peak
Privacy	Query logs may be retained long-term; may sell data
Security	DNSSEC validation varies; malware blocking uncommon
Reliability	Generally good; single point of failure for ISP
CDN Optimization	Best—CDN sees accurate client location via resolver IP
Cost	Included with service
Filtering	May implement government-required blocks

The CDN Optimization Trade-off

Using your ISP's resolver often results in better CDN performance because CDNs use the resolver's IP to estimate user location. With a remote public resolver (or one without ECS), CDNs may serve content from suboptimal locations. Some public resolvers (like Google's) support ECS to mitigate this.

Privacy and Encrypted DNS

Traditional DNS queries are unencrypted—anyone on the network path can observe which domains you're resolving. This has significant privacy implications that modern encrypted DNS protocols address. The Privacy Problem:

Traditional DNS Privacy Issues

•ISP sees all queries — Your ISP can log every domain you access
•Network-level surveillance — Coffee shop WiFi operator, hotel network, etc.
•DNS hijacking — Attackers on the path can redirect queries
•Query metadata exposure — Even encrypted HTTPS sites leak their domains via DNS
•Persistent records — DNS logs can persist indefinitely, creating browsing history

Encrypted DNS Protocols: DNS-over-HTTPS (DoH) — RFC 8484 DNS queries and responses encapsulated in HTTPS: Uses standard HTTPS port 443 (hard to block) Queries look like regular web traffic Supported by major browsers (Firefox, Chrome, Edge) Endpoint examples: https://1.1.1.1/dns-query, https://dns.google/dns-query DNS-over-TLS (DoT) — RFC 7858 DNS over a TLS-encrypted connection: Uses dedicated port 853 Easier to identify and potentially block Supported by many resolver implementations Better for systems (vs applications) DNS-over-QUIC (DoQ) — RFC 9250 DNS over QUIC transport: Lower latency than DoT (0-RTT connections) Uses dedicated port (usually 853 or 8853) Relatively new, growing support

Encrypted DNS Protocol Comparison
Aspect	DoH	DoT	DoQ
Port	443 (HTTPS)	853	853 or 8853
Transport	HTTP/2 or HTTP/3 over TLS	TLS 1.2/1.3 over TCP	QUIC (UDP)
Blockability	Hard (blends with HTTPS)	Easy (unique port)	Moderate (unique port, UDP)
Latency	Higher (HTTP overhead)	Moderate	Lower (0-RTT capable)
Adoption	High (browsers)	Moderate (OS, resolvers)	Growing
Ideal for	User privacy, bypass	System-wide encryption	High-performance privacy

Configuring Encrypted DNS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Linux: systemd-resolved with DoT
# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com
DNSOverTLS=yes
 
# Verify DoT is working
$ resolvectl status
Current DNS Server: 1.1.1.1
        DNS over TLS: yes
 
# Test DoH with curl
$ curl -s "https://1.1.1.1/dns-query?name=example.com&type=A" \
    -H "accept: application/dns-json" | jq
 
# Firefox: Settings → Privacy & Security → Enable DNS over HTTPS
# Chrome: chrome://settings/security → Use secure DNS

Encrypted DNS Isn't Complete Privacy

While encrypted DNS hides query content, the destination IP is still visible in network traffic. Server Name Indication (SNI) in TLS handshakes also reveals the target hostname. For complete privacy, combine encrypted DNS with encrypted SNI (ECH) and VPN/Tor.

Resolver-Based Filtering

DNS resolvers can block or redirect queries for specific domains, enabling content filtering, ad blocking, and security protection. Filtering Mechanisms:

DNS Filtering Approaches

•NXDOMAIN Response: Return "domain doesn't exist" for blocked domains
•REFUSED Response: Explicitly refuse to resolve blocked domains
•Redirect (Sinkhole): Return special IP that displays block page
•RPZ (Response Policy Zones): BIND feature for zone-based filtering rules
•Blocklist Integration: Load threat intelligence feeds into resolver

Pi-hole: Popular DNS-Based Ad Blocker Pi-hole is a network-wide ad blocker that acts as a DNS sinkhole: ┌───────────────┐ ┌──────────────┐ ┌─────────────────┐ │ Client Device │────▶│ Pi-hole │────▶│ Upstream DNS │ │ │ │ (filtering) │ │ (8.8.8.8 etc) │ └───────────────┘ └──────────────┘ └─────────────────┘ │ ▼ ┌──────────────┐ │ Blocklist │ │(ads, trackers)│ └──────────────┘ Common filter categories: Ad networks (blocks ad server domains) Tracking domains (analytics, trackers) Malware domains (known bad domains) Phishing domains (credential theft sites) Adult content (parental controls) Social media (productivity/parental) Gambling sites (regulatory compliance)

DNS Filtering Solutions
Solution	Type	Key Features	Best For
Pi-hole	Self-hosted	Web UI, extensive blocklists, local DNS	Home/small office
AdGuard Home	Self-hosted	DoH/DoT support, parental controls	Privacy-focused homes
OpenDNS Family	Cloud service	Preset filters, easy setup	Simple parental controls
Quad9	Cloud service	Threat blocking only	Security without overblocking
CleanBrowsing	Cloud service	Family/Adult/Security levels	Schools, families
NextDNS	Cloud service	Customizable, analytics	Advanced users

Bypass Challenges

DNS filtering can be bypassed by applications using their own resolvers (like browsers with DoH) or hardcoded DNS servers. Enterprise environments may need to block port 853 (DoT), require proxy use for HTTPS, or use certificate inspection to prevent bypass. Mobile devices with cellular data can bypass network-level DNS controls entirely.

DNSSEC Validation

DNSSEC (DNS Security Extensions) provides cryptographic authentication of DNS responses. Resolvers play a critical role in validating DNSSEC signatures to protect clients from cache poisoning and spoofing. How DNSSEC Validation Works: Zone Signing: Authoritative servers sign their zone data with cryptographic keys Chain of Trust: Each zone's public key is signed by the parent zone (DS record) Root Trust Anchor: The root zone's key is pre-configured in validators Validation: Resolver verifies signatures and chain from root to queried domain

Converting Mermaid diagram...

Resolver DNSSEC Configuration:

DNSSEC Validation Configuration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Unbound configuration (common validating resolver)
server:
    # Enable DNSSEC validation
    module-config: "validator iterator"
    
    # Trust anchor auto-update (RFC 5011)
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    
    # Log validation failures
    val-log-level: 1
 
# BIND 9 configuration
options {
    dnssec-validation auto;  # Use built-in root keys
};
 
# Verify DNSSEC validation is working
$ dig www.example.com +dnssec
 
# AD flag = Authenticated Data (DNSSEC validated)
;; flags: qr rd ra ad;
 
# Check a specific domain's DNSSEC chain
$ delv example.com A +rtrace

DNSSEC Validation Outcomes
Outcome	AD Flag	Response Code	Meaning
Validated (secure)	AD=1	NOERROR	Signature chain verified successfully
Not signed (insecure)	AD=0	NOERROR	Domain not DNSSEC-signed, returned anyway
Validation failed (bogus)	AD=0	SERVFAIL	Signature verification failed
Algorithm issue	AD=0	SERVFAIL	Unsupported algorithm or missing keys

DNSSEC Failure Impact

When DNSSEC validation fails, a validating resolver returns SERVFAIL, effectively blocking access to the domain. This can occur due to: expired signatures (zone operator didn't re-sign), key rollover mistakes, or clock skew on the resolver. Monitor DNSSEC-signed zones carefully and have rollback procedures ready.

Computer NetworksDNS Resolution

DNS Resolution

LevelIntermediate

Duration60 mins

TopicDNS Resolution

4 / 5

Resolver Role

The Unsung Hero of DNS

Every DNS query you make—every website visit, email sent, app connection—flows through a DNS resolver. Yet most users never think about which resolver they use or what that resolver does beyond basic name-to-IP translation. The resolver is far more than a lookup service. It's a caching engine, a security gateway, a privacy boundary, and often a policy enforcement point . The choice of resolver affects your browsing speed, your protection from malicious domains, and who can observe your Internet activity. In this page, we explore the resolver's multifaceted role, examining configuration options, extended services, and the profound implications of resolver selection.

What You Will Learn

By the end of this page, you will understand: (1) The complete set of services a resolver provides, (2) Types of resolvers and their characteristics, (3) How resolvers are configured across different systems, (4) Privacy and security implications of resolver choice, and (5) Advanced resolver features like filtering and DNSSEC validation.

Resolver Responsibilities

A recursive DNS resolver performs many more functions than simply translating names to addresses. Understanding these responsibilities reveals why resolver choice matters. Core Resolution Functions:

Primary Resolver Duties

•Query Processing: Accept client queries, validate format, parse question section
•Cache Management: Store responses with TTL, evict expired entries, handle negative caching
•Iterative Resolution: Navigate DNS hierarchy from root through TLD to authoritative servers
•Response Construction: Assemble answer from cached data or fresh resolution
•Error Handling: Detect failures, retry with alternate servers, return appropriate RCODE

Extended Services: Modern resolvers provide capabilities far beyond basic resolution:

Extended Resolver Services
Service	Description	Value
DNSSEC Validation	Verify cryptographic signatures on responses	Prevents cache poisoning and spoofing
Malware Blocking	Block domains known to host malware	Protects clients from infections
Phishing Protection	Block domains used for credential theft	Reduces phishing success rates
Content Filtering	Block categories of content (adult, gambling, etc.)	Parental controls, workplace policy
Anycast Distribution	Serve from geographically distributed locations	Reduces latency globally
Query Logging	Record what domains clients resolve	Security analysis, compliance (with privacy concerns)
Rate Limiting	Limit query rates per client	Prevents abuse, DDoS mitigation
Split-Horizon	Return different results for internal vs external clients	Internal resource access

The Resolver as Security Control Point

Because all DNS queries flow through the resolver, it's a natural enforcement point for security policies. Blocking malicious domains at the resolver prevents connections before they start—more efficient than detecting malware after download or blocking IPs at the firewall.

Resolver Types

Different environments use different resolver types, each with distinct characteristics: Stub Resolver (Client Resolver) The simplest form—a lightweight component on end-user devices: Implements only the client side of DNS protocol Sends recursive queries, expects complete answers Minimal caching (sometimes none, sometimes OS-level cache) Configured with upstream resolver address Examples: Windows DNS Client service, glibc resolver, systemd-resolved Recursive Resolver (Caching Resolver) The workhorse of DNS infrastructure: Accepts recursive queries from clients Performs iterative resolution through DNS hierarchy Maintains comprehensive cache May provide filtering, logging, security features Examples: BIND, Unbound, PowerDNS Recursor, Knot Resolver

Full Recursive Resolver

•Resolves from root hints (complete independence)
•Maximum control over resolution behavior
•Can apply custom policies at every step
•Higher resource requirements
•Good for: ISPs, enterprises, privacy-focused setups

Forwarding Resolver

•Forwards queries to upstream recursive resolver
•Caches responses locally
•Lower resource usage
•Depends on upstream reliability
•Good for: Home routers, edge caching, local filtering

Authoritative-Only Resolver Some servers only answer authoritatively for configured zones: No recursion for external queries Responds with referrals for non-local zones Often part of enterprise internal DNS Hybrid Configurations Many deployments combine roles: Authoritative for internal zones, forwarding for external Recursive for trusted clients, referral-only for others Local cache + upstream resolver for redundancy

Popular DNS Resolver Software
Software	Type	Key Features	Common Use
BIND 9	Full recursive + authoritative	Industry standard, comprehensive features	ISPs, enterprises, root servers
Unbound	Recursive only	Fast, secure, DNSSEC validation	ISPs, privacy resolvers
PowerDNS Recursor	Recursive only	High performance, Lua scripting	Large-scale deployment
Knot Resolver	Recursive only	Modular, modern design	Research, specialized deployments
dnsmasq	Forwarding + DHCP	Lightweight, integrated services	Home routers, small networks
systemd-resolved	Stub + local cache	Integrated with systemd	Modern Linux desktops
CoreDNS	Modular, plugin-based	Kubernetes DNS, cloud-native	Container orchestration

Resolver Configuration

Resolver configuration varies across operating systems and network environments. Understanding these mechanisms is essential for troubleshooting and customization. Linux Configuration:

/etc/resolv.conf (Traditional Linux)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# Primary nameserver (queried first)
nameserver 8.8.8.8
 
# Secondary nameserver (failover)
nameserver 8.8.4.4
 
# Local resolver (common with systemd-resolved)
nameserver 127.0.0.53
 
# Search domains (appended to short names)
search example.com corp.example.com
 
# Options
options timeout:2 attempts:3 rotate ndots:1
 
# timeout:N  - Wait N seconds for reply
# attempts:N - Try N times before giving up
# rotate     - Round-robin nameservers instead of failover order
# ndots:N    - Names with < N dots get search domain appended

systemd-resolved (Modern Linux): Modern Linux distributions use systemd-resolved, which provides: Local caching stub resolver (127.0.0.53) Per-interface DNS configuration DNSSEC validation DNS-over-TLS support

systemd-resolved Configuration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# /etc/systemd/resolved.conf
[Resolve]
DNS=8.8.8.8 8.8.4.4
FallbackDNS=1.1.1.1 9.9.9.9
Domains=~.
DNSSEC=yes
DNSOverTLS=opportunistic
 
# View current status
$ resolvectl status
 
# Query using resolved
$ resolvectl query www.example.com
 
# Show cache statistics
$ resolvectl statistics

Windows Configuration: Windows manages DNS at the network adapter level: Control Panel \to Network Connections \to Adapter Properties \to IPv4/IPv6 Properties PowerShell/Command Prompt:

Windows DNS Configuration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# View current DNS settings
Get-DnsClientServerAddress
 
# Set DNS servers for an interface
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("8.8.8.8","8.8.4.4")
 
# View DNS cache
Get-DnsClientCache
 
# Clear DNS cache
Clear-DnsClientCache
 
# Test resolution
Resolve-DnsName www.example.com
Resolve-DnsName www.example.com -Server 1.1.1.1

Mobile Devices:

Platform	Default Behavior	Custom DNS Options
iOS	Uses DHCP-provided	Wi-Fi settings, DNS profiles, Private Relay
Android	Uses DHCP-provided	Private DNS (DoT), per-network settings

Enterprise Environments: In enterprise networks, DNS is typically managed centrally: DHCP assigns DNS — DHCP option 6 provides resolver addresses Active Directory DNS — Domain controllers provide internal DNS Split-brain DNS — Internal resolvers for internal names, external for public Group Policy — Centrally managed DNS settings

DNS Configuration Precedence

Be aware of precedence: VPN DNS settings often override system settings. Containers may use different resolvers than the host. Applications may override system resolvers (e.g., browsers with DoH). When troubleshooting, verify which resolver is actually being used for the specific application.

Public vs Private Resolvers

The choice between public resolvers and ISP/private resolvers involves trade-offs in performance, privacy, and features. Major Public Resolvers:

Major Public DNS Resolvers
Provider	IPv4 Address	IPv6 Address	Notable Features
Google Public DNS	8.8.8.8, 8.8.4.4	2001:4860:4860::8888	High performance, ECS support, logging (anonymized after 24h)
Cloudflare DNS	1.1.1.1, 1.0.0.1	2606:4700:4700::1111	Privacy-focused, WARP VPN option, no query logging
Quad9	9.9.9.9, 149.112.112.112	2620:fe::fe	Threat blocking, non-profit, DNSSEC by default
OpenDNS (Cisco)	208.67.222.222	—	Content filtering, enterprise options
Comodo Secure	8.26.56.26	—	Malware blocking
CleanBrowsing	185.228.168.168	—	Family filter, adult content blocking

Public Resolver Advantages

•Often faster than ISP resolvers
•More reliable (better infrastructure)
•Advanced security features (DNSSEC, malware blocking)
•Privacy options (no logging, encrypted DNS)
•Bypass ISP DNS manipulation

Public Resolver Concerns

•Single entity sees all your DNS queries
•May impact CDN optimization (wrong ECS)
•Regulatory concerns in some jurisdictions
•Trust in provider's privacy commitment
•Potential single point of failure

ISP Resolver Characteristics:

Factor	Typical ISP Resolver
Performance	Variable; may be overloaded during peak
Privacy	Query logs may be retained long-term; may sell data
Security	DNSSEC validation varies; malware blocking uncommon
Reliability	Generally good; single point of failure for ISP
CDN Optimization	Best—CDN sees accurate client location via resolver IP
Cost	Included with service
Filtering	May implement government-required blocks

The CDN Optimization Trade-off

Using your ISP's resolver often results in better CDN performance because CDNs use the resolver's IP to estimate user location. With a remote public resolver (or one without ECS), CDNs may serve content from suboptimal locations. Some public resolvers (like Google's) support ECS to mitigate this.

Privacy and Encrypted DNS

Traditional DNS queries are unencrypted—anyone on the network path can observe which domains you're resolving. This has significant privacy implications that modern encrypted DNS protocols address. The Privacy Problem:

Traditional DNS Privacy Issues

•ISP sees all queries — Your ISP can log every domain you access
•Network-level surveillance — Coffee shop WiFi operator, hotel network, etc.
•DNS hijacking — Attackers on the path can redirect queries
•Query metadata exposure — Even encrypted HTTPS sites leak their domains via DNS
•Persistent records — DNS logs can persist indefinitely, creating browsing history

Encrypted DNS Protocols: DNS-over-HTTPS (DoH) — RFC 8484 DNS queries and responses encapsulated in HTTPS: Uses standard HTTPS port 443 (hard to block) Queries look like regular web traffic Supported by major browsers (Firefox, Chrome, Edge) Endpoint examples: https://1.1.1.1/dns-query, https://dns.google/dns-query DNS-over-TLS (DoT) — RFC 7858 DNS over a TLS-encrypted connection: Uses dedicated port 853 Easier to identify and potentially block Supported by many resolver implementations Better for systems (vs applications) DNS-over-QUIC (DoQ) — RFC 9250 DNS over QUIC transport: Lower latency than DoT (0-RTT connections) Uses dedicated port (usually 853 or 8853) Relatively new, growing support

Encrypted DNS Protocol Comparison
Aspect	DoH	DoT	DoQ
Port	443 (HTTPS)	853	853 or 8853
Transport	HTTP/2 or HTTP/3 over TLS	TLS 1.2/1.3 over TCP	QUIC (UDP)
Blockability	Hard (blends with HTTPS)	Easy (unique port)	Moderate (unique port, UDP)
Latency	Higher (HTTP overhead)	Moderate	Lower (0-RTT capable)
Adoption	High (browsers)	Moderate (OS, resolvers)	Growing
Ideal for	User privacy, bypass	System-wide encryption	High-performance privacy

Configuring Encrypted DNS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Linux: systemd-resolved with DoT
# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com
DNSOverTLS=yes
 
# Verify DoT is working
$ resolvectl status
Current DNS Server: 1.1.1.1
        DNS over TLS: yes
 
# Test DoH with curl
$ curl -s "https://1.1.1.1/dns-query?name=example.com&type=A" \
    -H "accept: application/dns-json" | jq
 
# Firefox: Settings → Privacy & Security → Enable DNS over HTTPS
# Chrome: chrome://settings/security → Use secure DNS

Encrypted DNS Isn't Complete Privacy

While encrypted DNS hides query content, the destination IP is still visible in network traffic. Server Name Indication (SNI) in TLS handshakes also reveals the target hostname. For complete privacy, combine encrypted DNS with encrypted SNI (ECH) and VPN/Tor.

Resolver-Based Filtering

DNS resolvers can block or redirect queries for specific domains, enabling content filtering, ad blocking, and security protection. Filtering Mechanisms:

DNS Filtering Approaches

•NXDOMAIN Response: Return "domain doesn't exist" for blocked domains
•REFUSED Response: Explicitly refuse to resolve blocked domains
•Redirect (Sinkhole): Return special IP that displays block page
•RPZ (Response Policy Zones): BIND feature for zone-based filtering rules
•Blocklist Integration: Load threat intelligence feeds into resolver

Pi-hole: Popular DNS-Based Ad Blocker Pi-hole is a network-wide ad blocker that acts as a DNS sinkhole: ┌───────────────┐ ┌──────────────┐ ┌─────────────────┐ │ Client Device │────▶│ Pi-hole │────▶│ Upstream DNS │ │ │ │ (filtering) │ │ (8.8.8.8 etc) │ └───────────────┘ └──────────────┘ └─────────────────┘ │ ▼ ┌──────────────┐ │ Blocklist │ │(ads, trackers)│ └──────────────┘ Common filter categories: Ad networks (blocks ad server domains) Tracking domains (analytics, trackers) Malware domains (known bad domains) Phishing domains (credential theft sites) Adult content (parental controls) Social media (productivity/parental) Gambling sites (regulatory compliance)

DNS Filtering Solutions
Solution	Type	Key Features	Best For
Pi-hole	Self-hosted	Web UI, extensive blocklists, local DNS	Home/small office
AdGuard Home	Self-hosted	DoH/DoT support, parental controls	Privacy-focused homes
OpenDNS Family	Cloud service	Preset filters, easy setup	Simple parental controls
Quad9	Cloud service	Threat blocking only	Security without overblocking
CleanBrowsing	Cloud service	Family/Adult/Security levels	Schools, families
NextDNS	Cloud service	Customizable, analytics	Advanced users

Bypass Challenges

DNS filtering can be bypassed by applications using their own resolvers (like browsers with DoH) or hardcoded DNS servers. Enterprise environments may need to block port 853 (DoT), require proxy use for HTTPS, or use certificate inspection to prevent bypass. Mobile devices with cellular data can bypass network-level DNS controls entirely.

DNSSEC Validation

DNSSEC (DNS Security Extensions) provides cryptographic authentication of DNS responses. Resolvers play a critical role in validating DNSSEC signatures to protect clients from cache poisoning and spoofing. How DNSSEC Validation Works: Zone Signing: Authoritative servers sign their zone data with cryptographic keys Chain of Trust: Each zone's public key is signed by the parent zone (DS record) Root Trust Anchor: The root zone's key is pre-configured in validators Validation: Resolver verifies signatures and chain from root to queried domain

Converting Mermaid diagram...

Resolver DNSSEC Configuration:

DNSSEC Validation Configuration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Unbound configuration (common validating resolver)
server:
    # Enable DNSSEC validation
    module-config: "validator iterator"
    
    # Trust anchor auto-update (RFC 5011)
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    
    # Log validation failures
    val-log-level: 1
 
# BIND 9 configuration
options {
    dnssec-validation auto;  # Use built-in root keys
};
 
# Verify DNSSEC validation is working
$ dig www.example.com +dnssec
 
# AD flag = Authenticated Data (DNSSEC validated)
;; flags: qr rd ra ad;
 
# Check a specific domain's DNSSEC chain
$ delv example.com A +rtrace

DNSSEC Validation Outcomes
Outcome	AD Flag	Response Code	Meaning
Validated (secure)	AD=1	NOERROR	Signature chain verified successfully
Not signed (insecure)	AD=0	NOERROR	Domain not DNSSEC-signed, returned anyway
Validation failed (bogus)	AD=0	SERVFAIL	Signature verification failed
Algorithm issue	AD=0	SERVFAIL	Unsupported algorithm or missing keys

DNSSEC Failure Impact

When DNSSEC validation fails, a validating resolver returns SERVFAIL, effectively blocking access to the domain. This can occur due to: expired signatures (zone operator didn't re-sign), key rollover mistakes, or clock skew on the resolver. Monitor DNSSEC-signed zones carefully and have rollback procedures ready.

Resolver Role

The Unsung Hero of DNS

Resolver Responsibilities

Resolver Types

Resolver Configuration

Public vs Private Resolvers

Privacy and Encrypted DNS

Resolver-Based Filtering

DNSSEC Validation

There’s more to understand.

Resolver Role

The Unsung Hero of DNS

Resolver Responsibilities

Resolver Types

Resolver Configuration

Public vs Private Resolvers

Privacy and Encrypted DNS

Resolver-Based Filtering

DNSSEC Validation

There’s more to understand.