Self-Hosted DNS Caching Resolvers: Unbound vs dnscrypt-proxy vs BIND (2026)

A DNS caching resolver sits between your network and upstream DNS servers, storing query results to reduce latency, improve reliability, and provide a first line of defense against DNS-based threats. Whether you’re running a home lab or managing enterprise infrastructure, choosing the right caching resolver impacts every network operation.

This guide compares three mature, open-source DNS caching resolvers — Unbound, dnscrypt-proxy, and BIND — each taking a different approach to DNS resolution and caching.

What Does a DNS Caching Resolver Do?

When a device on your network requests a domain name, the caching resolver checks its local cache first. If the record exists and hasn’t expired (based on TTL), it returns the cached answer immediately — typically in under 1 millisecond. If not cached, it queries upstream authoritative servers, stores the result, and returns it. This process repeats for every unique query, building up a cache that accelerates subsequent lookups for popular domains.

Beyond speed, caching resolvers provide DNSSEC validation, query logging, access control lists, and support for encrypted DNS protocols (DNS-over-TLS, DNS-over-HTTPS). They also reduce the load on upstream resolvers and provide a centralized point for DNS policy enforcement.

Quick Comparison

Unbound: The Validating Recursive Resolver

Unbound from NLnet Labs is a lightweight, validating, recursive, caching DNS resolver. It performs full recursive resolution — starting from the root servers and walking the DNS hierarchy — while validating DNSSEC signatures at every step.

Key Features

• Full recursive resolution — Walks the DNS tree from root servers independently
• DNSSEC validation — Strict validation of cryptographic DNS signatures
• DNS-over-TLS — Encrypted upstream queries via TLS
• Local zone support — Override DNS records for internal domains
• Python module support — Extend with Python scripts for custom logic
• Low resource usage — Runs comfortably on a Raspberry Pi

Docker Compose Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

version: "3.8"
services:
  unbound:
    image: mvance/unbound:latest
    container_name: unbound
    restart: unless-stopped
    ports:
      - "53:53/tcp"
      - "53:53/udp"
    volumes:
      - ./unbound.conf:/opt/unbound/etc/unbound/unbound.conf:ro
      - ./root.hints:/opt/unbound/etc/unbound/root.hints:ro
    cap_add:
      - NET_BIND_SERVICE
    healthcheck:
      test: ["CMD", "drill", "-p", "53", "localhost", "@127.0.0.1"]
      interval: 30s
      timeout: 5s
      retries: 3

Configuration Highlights

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# unbound.conf
server:
  interface: 0.0.0.0
  port: 53
  access-control: 192.168.0.0/16 allow
  access-control: 10.0.0.0/8 allow
  
  # DNSSEC validation
  auto-trust-anchor-file: /opt/unbound/etc/unbound/root.key
  
  # DNS-over-TLS upstream
  tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
  
  # Forwarding (optional — for mixed setups)
  forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 9.9.9.9@853#dns.quad9.net
  
  # Local domain overrides
  local-zone: "internal.example.com." static
  local-data: "server.internal.example.com. A 192.168.1.10"
  
  # Cache settings
  cache-min-ttl: 300
  cache-max-ttl: 86400
  msg-cache-size: 128m

When to Choose Unbound

Unbound is the right choice when you want a dedicated recursive resolver that performs its own DNSSEC validation and doesn’t depend on upstream resolvers for security. It’s ideal for organizations that need full control over the resolution path, including compliance environments that mandate DNSSEC validation.

dnscrypt-proxy: The Encrypted DNS Proxy

dnscrypt-proxy is not a recursive resolver — it’s a local DNS proxy that encrypts your queries before forwarding them to upstream resolvers that support DNSCrypt, DNS-over-HTTPS, or DNS-over-TLS.

Key Features

• Multiple encrypted protocols — DNSCrypt v2, DoH, DoT, and plain DNS
• Anonymized DNS relays — Route queries through relay servers to hide your IP
• Built-in blocking — Filter ads, malware, and tracking domains via blocklists
• Load balancing — Distribute queries across multiple upstream resolvers
• Cloaking rules — Map domains to specific IPs or other domains
• Caching — Local response cache with configurable TTL

Docker Compose Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

version: "3.8"
services:
  dnscrypt-proxy:
    image: ghcr.io/dnscrypt/dnscrypt-proxy:latest
    container_name: dnscrypt-proxy
    restart: unless-stopped
    ports:
      - "53:53/tcp"
      - "53:53/udp"
    volumes:
      - ./dnscrypt-proxy.toml:/config/dnscrypt-proxy.toml:ro
      - ./blocklists:/config/blocklists
    cap_add:
      - NET_BIND_SERVICE
    healthcheck:
      test: ["CMD", "wget", "--spider", "-q", "http://127.0.0.1:53"]
      interval: 30s
      timeout: 5s
      retries: 3

Configuration Highlights

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# dnscrypt-proxy.toml
listen_addresses = ['0.0.0.0:53']

# Upstream resolvers (DoH)
server_names = ['cloudflare', 'quad9', 'google']

# DNSCrypt resolvers
[static.'mystatic']
stamp = 'sdns://AQcAAAAAAAAAAAAQOS45LjkuOQ'

# Caching
cache = true
cache_size = 512
cache_min_ttl = 60
cache_max_ttl = 86400

# Blocking (blocklists)
[blocked_names]
blocked_names_file = '/config/blocklists/blocklist.txt'

# Cloaking (local DNS overrides)
[cloaking_rules]
cloaking_rules_file = '/config/cloaking-rules.txt'

# Load balancing across resolvers
lb_strategy = 'ph'  # Pseudo-hashing
lb_estimator = true

When to Choose dnscrypt-proxy

dnscrypt-proxy excels when encryption and privacy are your primary concerns. If you want to prevent ISP-level DNS snooping, use anonymized DNS relays, or block ads and malware domains at the DNS level, dnscrypt-proxy is the strongest option. It’s also the easiest to configure for home lab users who want encrypted DNS without running a full recursive resolver.

BIND: The Enterprise DNS Server

BIND (Berkeley Internet Name Domain) is the most widely deployed DNS server software. While primarily known as an authoritative DNS server, BIND also operates as a recursive caching resolver with full DNSSEC support.

Key Features

• Dual role — Authoritative and recursive caching in the same server
• DNSSEC full support — Signing, validation, and key management
• DNS-over-TLS and DNS-over-HTTPS — Encrypted query support
• Response Policy Zones — Advanced DNS filtering and policy enforcement
• Views — Serve different DNS data based on client IP
• DLZ — Dynamic loading of zones from databases

Docker Compose Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

version: "3.8"
services:
  bind9:
    image: ubuntu/bind9:latest
    container_name: bind9
    restart: unless-stopped
    environment:
      - BIND9_USER=bind
    ports:
      - "53:53/tcp"
      - "53:53/udp"
    volumes:
      - ./named.conf:/etc/bind/named.conf:ro
      - ./zones:/etc/bind/zones
      - bind-data:/var/cache/bind
    cap_add:
      - NET_BIND_SERVICE
    healthcheck:
      test: ["CMD", "rndc", "status"]
      interval: 30s
      timeout: 5s
      retries: 3

volumes:
  bind-data:

Configuration Highlights

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

# named.conf
options {
    directory "/var/cache/bind";
    
    // Listen on all interfaces
    listen-on { any; };
    listen-on-v6 { any; };
    
    // Allow queries from internal networks
    allow-query { 192.168.0.0/16; 10.0.0.0/8; };
    allow-recursion { 192.168.0.0/16; 10.0.0.0/8; };
    
    // DNSSEC validation
    dnssec-validation auto;
    
    // DNS-over-TLS
    tls bind-tls {
        cert-file "/etc/bind/tls/server.crt";
        key-file "/etc/bind/tls/server.key";
    };
    
    // Upstream forwarders
    forwarders {
        1.1.1.1;
        9.9.9.9;
    };
    
    // Cache settings
    max-cache-size 256m;
    max-cache-ttl 86400;
};

// Authoritative zone (optional)
zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
};

When to Choose BIND

BIND is the right choice when you need both authoritative and recursive caching DNS in a single server. If you’re managing your own domain zones while also providing caching resolution for internal clients, BIND eliminates the need for separate authoritative and caching servers. It’s also the best choice for organizations that need DNS views, Response Policy Zones, or database-backed zone storage.

Self-Hosted DNS Infrastructure Benefits

Running your own DNS caching resolver gives you visibility into every query on your network, control over which upstream resolvers you trust, and the ability to enforce DNS-level security policies. Encrypted DNS prevents man-in-the-middle attacks on name resolution, while DNSSEC validation ensures responses haven’t been tampered with. For organizations with compliance requirements, a self-hosted resolver provides audit trails and query logging that public resolvers cannot offer.

For complementary DNS infrastructure, see our DNS over TLS/QUIC guide and authoritative DNS comparison.

FAQ

What is the difference between a recursive resolver and a forwarding resolver?

A recursive resolver walks the entire DNS tree from root servers to find answers independently. A forwarding resolver passes queries to an upstream resolver (like Cloudflare or Google) and caches the results. Unbound and BIND can operate as recursive resolvers; dnscrypt-proxy is a forwarding proxy only.

Do I need DNSSEC validation?

DNSSEC validation protects against DNS spoofing and cache poisoning attacks by cryptographically verifying that responses come from the authoritative source. For production environments and any organization handling sensitive data, DNSSEC validation is strongly recommended.

Can I run multiple caching resolvers together?

Yes. A common setup uses dnscrypt-proxy as the local DNS proxy (handling encryption and blocking) with Unbound as the recursive resolver behind it. dnscrypt-proxy encrypts queries and forwards them to Unbound, which performs recursive resolution and DNSSEC validation.

How much memory does a DNS cache need?

For a typical home or small office network (10-50 devices), 64-128MB of cache memory is sufficient. Enterprise networks with hundreds of devices may benefit from 256-512MB. All three tools allow you to configure cache size limits.

Which tool is easiest to set up?

dnscrypt-proxy is generally the easiest — it ships with a sensible default configuration and a pre-populated list of encrypted DNS resolvers. Unbound requires slightly more configuration for recursive mode. BIND has the most complex setup due to its comprehensive feature set.

Can these tools block ads and malware domains?

dnscrypt-proxy has built-in blocklist support with automatic updates. Unbound supports local zone overrides and can block domains via configuration. BIND can use Response Policy Zones (RPZ) for enterprise-grade DNS filtering.