{"id":447,"date":"2026-09-07T07:50:00","date_gmt":"2026-09-07T05:50:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?p=447"},"modified":"2026-10-24T00:58:26","modified_gmt":"2026-10-23T22:58:26","slug":"zero-trust-dns-infrastructure-unbound-pi-hole-with-doh-and-dnssec","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/it-networks\/tutorials-en-it-networks\/zero-trust-dns-infrastructure-unbound-pi-hole-with-doh-and-dnssec\/","title":{"rendered":"Zero-Trust DNS Infrastructure: Unbound & Pi-hole with DoH and DNSSEC"},"content":{"rendered":"
Pi-hole and Unbound perform different jobs: Pi-hole filters DNS names against rules, while Unbound resolves allowed queries and validates DNSSEC. A central public resolver is no longer the upstream collection point. Root, TLD and authoritative DNS infrastructure remains necessary. This combination alone does not establish a complete zero-trust architecture.<\/p>\n
1. Filtering, recursion and DNSSEC<\/h2>\n
DNS maps names such as example.com<\/code> to addresses. A public resolver can record received names, but ordinary DNS requests do not include complete URL paths, page contents or every piece of network metadata.<\/p>\n
\n
Pi-hole:<\/strong> handles requests from devices actually configured to use Pi-hole. Domain blocklists are not comprehensive advertising or malware detection. Browsers using a separate DoH service can bypass the local filter.<\/li>\n
Unbound:<\/strong> resolves allowed requests that cannot be answered from cache. Referrals lead from root to TLD to authoritative servers; cached records can shorten this process.<\/li>\n
DNSSEC:<\/strong> validates signed DNS data through a chain of trust. Invalid signatures cause rejection. Zones securely identified as unsigned remain usable, without cryptographic authentication of their answers. DNSSEC does not encrypt requests.<\/li>\n<\/ul>\nPi-hole filters configured clients; Unbound resolves and validates signed DNS data. Direct recursion normally uses unencrypted transport.<\/figcaption><\/figure>\n
2. Example for Debian or Raspberry Pi OS<\/h2>\n
This example assumes Pi-hole and Unbound share a host and network namespace, without separate container networks. Changes to an active DNS service can interrupt name resolution, so the existing configuration and an accessible administration route need to be preserved. Recursion requires outbound UDP and TCP port 53.<\/p>\n
Installation from maintained distribution packages:<\/p>\n
The existing package configuration under \/etc\/unbound\/<\/code> needs checking before adding settings. Debian packages normally configure root hints and the DNSSEC trust anchor. An existing auto-trust-anchor-file<\/code> declaration must not be duplicated for the same file. The Unbound service needs write access to the automatically maintained anchor. If this setup is absent, the distribution package instructions take precedence.<\/p>\n
The following fragment for \/etc\/unbound\/unbound.conf.d\/pi-hole.conf<\/code> supplements that package configuration:<\/p>\n
do-ip6: no<\/code> selects IPv4 transport here; AAAA records remain available. Working native IPv6 connectivity can justify yes<\/code>. This fragment deliberately omits a second trust-anchor declaration and is not a complete standalone configuration.<\/p>\n
A successful configuration check must precede a restart. These commands are separate steps; a failed first check means the restart must not proceed:<\/p>\n
The first DNS test should return SERVFAIL<\/code>; the second should return NOERROR<\/code> with ad<\/code> among the flags. A single SERVFAIL<\/code> does not prove validation works: connectivity failures can cause the same result. Accurate system time is required for DNSSEC. restart<\/code> does not enable startup at boot; is-enabled<\/code> checks the existing setting.<\/p>\n
3. Connecting Pi-hole and checking the actual path<\/h2>\n
In Settings > DNS<\/code>, the custom upstream becomes 127.0.0.1#5335<\/code>. Other upstreams are removed for exclusively local recursion. After saving, a test request to Pi-hole should show Unbound as the forwarding destination in the query log. With separate containers, 127.0.0.1<\/code> refers to each container itself and is unsuitable for this connection.<\/p>\n
Use DNSSEC<\/code> enables additional validation inside Pi-hole; this is not merely status-flag forwarding. Unbound validates independently. If the extra validation is enabled, both DNSSEC tests need repeating through Pi-hole. Existing openresolv<\/code> or unbound-resolvconf<\/code> integration also needs checking: a resolver entry using port 53 must not create a loop back to the local service.<\/p>\n
4. DoH is a different operating mode<\/h2>\n
Ordinary direct recursion sends unencrypted DNS requests outside the network. QNAME minimisation reduces the name components disclosed to individual servers, but an observer on the internet connection can still read requests.<\/p>\n
A deliberately configured DoH upstream encrypts the connection to a selected resolver. That resolver receives the forwarded names. This is an alternative architecture, not an automatic fallback. Adding another Pi-hole upstream does not establish a guaranteed failover order. Certificate verification, bootstrap resolution and outage behaviour require their own configuration.<\/p>\n
cloudflared proxy-dns<\/code> was removed starting with version 2026.2.0 and is no longer a current installation option. Unbound’s documented DoH support for incoming client requests must also be distinguished from outgoing DoH forwarding.<\/p>\n
\n
Questions and answers<\/h2>\n
Does this prevent observation by the internet provider?<\/h3>\n
Direct recursion alone does not. DoH protects the contents of the corresponding DNS connection; destination IP addresses of later connections generally remain visible. DNSSEC protects signed data against undetected modification, but prevents neither blocking nor attacks on unsigned DNS data. Encrypted client connections to a private recursive resolver are possible; this does not automatically encrypt the resolver-to-authoritative-server path.<\/p>\n
Why do answers containing private IP addresses disappear?<\/h3>\n
private-address<\/code> prevents public DNS answers from introducing the listed private addresses. A deliberately internal name may need a narrow exception such as private-domain: \"internal.example.com\"<\/code>. An exception for an entire domain also covers subdomains and weakens rebinding protection within that scope. Local records answered directly by Pi-hole do not pass through Unbound.<\/p>\n<\/div>\n
![\"Pi-hole](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/quality-447-20261024.png\")