Freorit

The DNS Privacy Problem

Every time a device on your network visits a website, it first asks a DNS server: "What IP address does this domain have?" These queries reveal more than they might initially appear to.

Even without knowing the actual page content, DNS logs create a detailed profile: which services are used, at what times, how frequently. This affects individuals — and businesses even more so.

The commonly recommended solution — Pi-hole — solves part of the problem, not all of it.

Pi-hole Alone: Good, But Incomplete

Pi-hole is a DNS filter: it receives all DNS queries from the network and blocks known advertising and tracking domains before a connection is established. That is effective and worthwhile.

Pi-hole does not resolve DNS queries itself. It forwards non-blocked queries to a configured upstream resolver — for example Quad9 or Cloudflare. That external resolver then sees all queries Pi-hole passes through.

The fundamental problem remains: a third party in the loop sees your DNS traffic. Unbound solves that.

Unbound: The Elegant Solution

Unbound is a validating, recursive DNS resolver. Rather than forwarding a query to an external provider, Unbound queries the authoritative nameservers directly — starting from the DNS root servers.

The process: Unbound first queries a root server (a.root-servers.net etc.), which responds with the responsible TLD nameserver (e.g. for .com). That server refers to the authoritative nameserver for the domain. Unbound resolves the query entirely without ever sending a complete query to a single external provider. The result is cached.

No external DNS provider therefore sees the complete DNS traffic of your network.

Architecture and Data Path

The data path after this setup:

Pi-hole is the only DNS listener on the network (port 53). Its upstream points exclusively to 127.0.0.1#5533 — Unbound on the same device. Unbound itself is only reachable via localhost and the local network, not publicly.

Installation

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

sudo apt update
sudo apt install unbound

sudo systemctl status unbound

sudo wget -O /etc/unbound/named.root \
https://www.internic.net/domain/named.root

Configuring Unbound

The following configuration is based on a production homelab setup. All security-relevant options are enabled and commented. Create or replace the configuration file:

server:
# ──────────────────────────────────────────────
# Network: listen on localhost only.
# Pi-hole forwards internally; external devices
# never speak to Unbound directly.
# ──────────────────────────────────────────────
interface: 127.0.0.1
port: 5533
do-ip4: yes
do-ip6: no
prefer-ip4: yes

# Access control:
# Refuse everything by default, then selectively allow.
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: 192.168.1.0/24 allow    # Adjust to your LAN subnet

# ──────────────────────────────────────────────
# Hide identity
# Do not reveal which software or version runs here.
# ──────────────────────────────────────────────
hide-identity: yes
hide-version: yes

# ──────────────────────────────────────────────
# QNAME minimisation (RFC 7816)
# Unbound sends only the minimal necessary part of the
# domain name to each nameserver — no server sees the
# full query except the authoritative nameserver.
# ──────────────────────────────────────────────
qname-minimisation: yes
qname-minimisation-strict: yes

# ──────────────────────────────────────────────
# DNSSEC hardening
# Responses are cryptographically validated.
# Manipulated or forged answers are detected and
# discarded.
# ──────────────────────────────────────────────
harden-glue: yes
harden-dnssec-stripped: yes
harden-below-nxdomain: yes
harden-referral-path: yes
harden-algo-downgrade: yes
harden-large-queries: yes
harden-short-bufsize: yes

# DNSSEC trust anchor (automatically updated)
auto-trust-anchor-file: "/var/lib/unbound/root.key"

# ──────────────────────────────────────────────
# Performance
# prefetch: nearly-expired cache entries are renewed
# before they expire.
# serve-expired: during refresh, the expired entry is
# served rather than making the client wait.
# cache-min-ttl: prevents entries with very short TTLs
# from unnecessarily polluting the cache.
# ──────────────────────────────────────────────
prefetch: yes
serve-expired: yes
cache-min-ttl: 4400
edns-buffer-size: 1232

# ──────────────────────────────────────────────
# Additional security options
# use-caps-for-id: 0x20 encoding as protection
# against cache poisoning attacks.
# aggressive-nsec: DNSSEC NSEC records are used
# to confirm negative answers without querying the
# authoritative server again.
# ──────────────────────────────────────────────
use-caps-for-id: yes
aggressive-nsec: yes
unwanted-reply-threshold: 10000

# ──────────────────────────────────────────────
# Root hints and local zones
# ──────────────────────────────────────────────
root-hints: "named.root"
do-not-query-localhost: no
insecure-lan-zones: yes
local-zone: "168.192.in-addr.arpa." nodefault

# ──────────────────────────────────────────────
# System paths
# ──────────────────────────────────────────────
tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"
username: "unbound"
directory: "/etc/unbound"

Test the configuration and restart the service:

sudo unbound-checkconf
sudo systemctl restart unbound
sudo systemctl enable unbound

Pointing Pi-hole to Unbound

For Pi-hole to use Unbound as its upstream, the custom DNS server must be configured in Pi-hole.

Pi-hole v6 (pihole.toml)

In Pi-hole v6, configuration is managed through /etc/pihole/pihole.toml. Adjust the upstream DNS section:

[dns]
# Unbound on the same device, port 5533
upstreams = [ "127.0.0.1#5533" ]

Pi-hole v5 (Admin Interface)

In Pi-hole v5 via the admin interface: Settings → DNS → Upstream DNS Servers. Remove all existing checkmarks, enter 127.0.0.1#5533 under "Custom 1 (IPv4)" and save.

Restart Pi-hole for the change to take effect:

sudo systemctl restart pihole-FTL

Network Hardening: UFW and TCP Wrappers

Pi-hole and Unbound should only be reachable from your own network. The following rules show a typical configuration that allows only LAN access.

UFW Firewall

UFW (Uncomplicated Firewall) on Debian/Ubuntu sets iptables rules without complex syntax. Goal: deny all incoming connections, then selectively allow the LAN.

# Default rules
sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH from LAN only (adjust subnet)
sudo ufw allow from 192.168.1.0/24 to any port 22

# DNS: Pi-hole on port 53
sudo ufw allow from 192.168.1.0/24 to any port 53

# Unbound directly (optional, for debugging)
sudo ufw allow from 192.168.1.0/24 to any port 5533

# Pi-hole admin interface (port 80/443)
sudo ufw allow from 192.168.1.0/24 to any port 80,443 proto tcp

# Enable UFW
sudo ufw enable
sudo ufw status verbose

TCP Wrappers (hosts.allow / hosts.deny)

TCP Wrappers is an additional access control layer that operates independently of the firewall. The combination of both increases security depth.

# All services: access only from LAN
ALL: 192.168.1.0/24

# PARANOID: reject hosts whose hostname does not match
# their resolved IP address (reverse DNS check).
# Protects against spoofing attempts.
ALL: PARANOID

Verification

After configuration, verify that everything works as expected.

Test Unbound Directly

On the Pi itself, send a query directly to Unbound:

dig google.com @127.0.0.1 -p 5533

Test Pi-hole as DNS

From a device on the network, use the Pi-hole IP as DNS:

# Adjust to your Pi's IP
dig google.com @192.168.1.x

Check Unbound Status

sudo systemctl status unbound
sudo journalctl -u unbound -n 50 --no-pager

Test DNSSEC Validation

This domain is intentionally signed with a broken DNSSEC record and should not be resolved by a correctly configured resolver:

dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5533

Bonus: WireGuard as an Additional Layer

Even with Unbound, your Internet Service Provider (ISP) can see all DNS queries that Unbound sends outbound — including the queried domain names in plaintext. DNS is unencrypted by default.

WireGuard addresses this as well: when DNS traffic is routed through a WireGuard tunnel, the ISP sees only encrypted WireGuard traffic, not the DNS queries themselves. The VPN endpoint (e.g. a VPS at a data centre) becomes the visible originator of the DNS queries.

Conclusion

Pi-hole without Unbound is like a letterbox with a lock, but the key is at the post office. Unbound makes the system complete.