Zero-Trust-DNS-Infrastruktur: Unbound & Pi-hole mit DoH und DNSSEC

Das Vertrauen in externe, öffentliche DNS-Resolver (wie 8.8.8.8 oder 1.1.1.1) bedeutet zwangsläufig, sämtliche Metadaten des gesamten Netzwerkverkehrs an Dritte zu übergeben. Selbst bei aktivierter Transportverschlüsselung können zentrale DNS-Anbieter Abfragen protokollieren und Profile der Internetnutzung erstellen. Der Aufbau einer Zero-Trust-DNS-Architektur durch die Kombination von Pi-hole mit dem rekursiven, validierenden Resolver Unbound eliminiert jegliche Abhängigkeiten von externen Dienstleistern. Durch die direkte Abfrage der DNS-Root-Server bei gleichzeitiger DNSSEC-Validierung wird kryptografische Integrität garantiert und Manipulationen durch den Internetanbieter werden unterbunden; vor dem Mitlesen auf der Leitung schützt das allein nicht.

1. Architektur-Prinzipien: Zero-Trust-DNS & Rekursion

In standardmäßigen Netzwerkkonfigurationen werden DNS-Anfragen an einen ISP oder öffentlichen Resolver weitergeleitet. Eine lokale Zero-Trust-Architektur trennt die Aufgabenbereiche stattdessen in zwei klar definierte Stufen:

• Pi-hole (DNS-Sinkhole & Filter-Engine): Fängt eingehende Abfragen lokaler Endgeräte ab und filtert Telemetrie-, Werbe- und bekannte Schad-Domains anhand von Blocklisten aus.
• Unbound (Rekursiver Resolver & Validator): Nimm legitime Abfragen von Pi-hole entgegen und fragt die weltweite DNS-Hierarchie (Root-Server → TLD-Server → Autorisative Nameserver) eigenständig ab. Jede Antwort wird vor der lokalen Zwischenspeicherung durch kryptografische DNSSEC-Signaturen validiert.

2. Schritt-für-Schritt-Installation und Härtung von Unbound

Für die Bereitstellung von Unbound als hochsicherer rekursiver Resolver auf einem Linux-System (z. B. Debian oder Raspberry Pi OS) ist folgende Vorgehensweise auszuführen:

1. Paketinstallation: Installation des Resolvers und der notwendigen DNS-Werkzeuge:
   sudo apt update && sudo apt install unbound unbound-anchor -y
2. Einrichtung des DNSSEC-Root-Trust-Anchors: Abruf des offiziellen DNSSEC-Root-Schlüssels zur Signaturprüfung:
   sudo unbound-anchor -a /var/lib/unbound/root.key
3. Konfiguration der gehärteten Resolver-Datei: Erstellung der Hauptkonfigurationsdatei unter /etc/unbound/unbound.conf.d/pi-hole.conf mit optimierten Sicherheits- und Datenschutzparametern:

   server:
       verbosity: 1
       interface: 127.0.0.1
       port: 5335
       do-ip4: yes
       do-udp: yes
       do-tcp: yes
   
       # Sicherheit & DNSSEC-Validierung
       auto-trust-anchor-file: "/var/lib/unbound/root.key"
       harden-glue: yes
       harden-dnssec-stripped: yes
       use-caps-for-id: no
       edns-buffer-size: 1232
       prefetch: yes
       num-threads: 1
   
       # Datenschutz-Härtung (Minimale Datenpreisgabe)
       qname-minimisation: yes
       hide-identity: yes
       hide-version: yes
       private-address: 10.0.0.0/8
       private-address: 172.16.0.0/12
       private-address: 192.168.0.0/16

4. Dienst-Neustart & Verifikation: Aktivierung und Neustart des Unbound-Dienstes sowie anschließender Test der lokalen Auflösung und DNSSEC-Prüfung über den definierten Port:
   sudo systemctl restart unbound
dig @127.0.0.1 -p 5335 dnssec-failed.org +dnssec (Muss aufgrund einer ungültigen DNSSEC-Signatur zwingend SERVFAIL zurückgeben).

3. Schritt-für-Schritt-Integration in Pi-hole & DoH-Fallback

Sobald die lokale Rekursion funktionsfähig ist, muss Pi-hole an den internen Unbound-Dienst angebunden werden:

1. Upstream-Konfiguration in Pi-hole: Aufrufen der Pi-hole Web-Oberfläche und Navigation zu Settings > DNS.
2. Deaktivierung externer Upstream-Anbieter: Entfernen sämtlicher Haken bei vorkonfigurierten, externen DNS-Servern (z. B. Google, Cloudflare, Quad9).
3. Eintragung des lokalen Custom-Upstreams: Im Feld Custom 1 (IPv4) wird der lokale Unbound-Socket eingetragen: 127.0.0.1#5335.
4. Aktivierung von DNSSEC: Setzen des Hakens bei Use DNSSEC, damit Pi-hole die kryptografischen DNSSEC-Statusflags korrekt an die lokalen Clients weiterreicht.
5. Optionales DNS-over-HTTPS (DoH)-Tunneling: In Netzwerkumgebungen mit restriktiver ISP-Überwachung auf Port 53 kann Unbound so konfiguriert werden, dass Abfragen über einen lokalen DoH-Proxy (z. B. cloudflared oder dnscrypt-proxy) verschlüsselt weitergeleitet werden, um ein Abhören auf Transitrouten zu verhindern.

4. Zusammenfassung & Mehrwert

Was sich damit erreichen lässt: Die erfolgreiche Implementierung einer autonomen Zero-Trust-DNS-Architektur, bei der die Werbe- und Tracking-Blockade von Pi-hole mit der kryptografischen DNSSEC-Validierung und Datenminimierung des rekursiven Unbound-Resolvers kombiniert wird.

Resultierender Mehrwert: Es wird eine vollständige Unabhängigkeit von kommerziellen DNS-Anbietern erreicht, sodass kein externer DNS-Anbieter mehr interne Netzwerkprofile oder Abfragelogbücher erfassen oder monetarisieren kann. Die kryptografische DNSSEC-Validierung schützt alle Geräte im lokalen Netz zuverlässig vor Cache-Poisoning, Spoofing und Man-in-the-Middle-Manipulationen, während die QNAME-Minimierung sicherstellt, dass jeweils nur das absolut notwendige Minimum an Domain-Informationen an übergeordnete DNS-Server übertragen wird.