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

Pi-hole und Unbound übernehmen zwei unterschiedliche Aufgaben: Pi-hole filtert DNS-Namen anhand von Regeln, Unbound ermittelt die zugehörigen Antworten und prüft DNSSEC. Damit entfällt ein zentraler öffentlicher Resolver als vorgeschaltete Sammelstelle. Abhängigkeiten von Root-, TLD- und autoritativen DNS-Servern bleiben bestehen. Die Kombination allein ergibt noch keine vollständige Zero-Trust-Architektur.

1. Was Filter, Rekursion und DNSSEC leisten

DNS übersetzt Namen wie example.com in Adressen. Ein öffentlicher Resolver kann die empfangenen Namen protokollieren; vollständige URL-Pfade, Seiteninhalte und sämtliche Netzwerkmetadaten gehören jedoch nicht zu einer gewöhnlichen DNS-Abfrage.

• Pi-hole: bearbeitet Abfragen von Geräten, die Pi-hole tatsächlich als DNS-Server verwenden. Blocklisten erfassen bestimmte Domains, keine vollständige Werbe- oder Schadsoftware-Erkennung. Browser mit eigenem DoH können den lokalen Filter umgehen.
• Unbound: beantwortet erlaubte, nicht bereits zwischengespeicherte Anfragen durch Rekursion. Dabei führen Verweise von Root- über TLD- zu autoritativen Servern; vorhandene Cache-Einträge verkürzen den Weg.
• DNSSEC: prüft signierte DNS-Daten anhand einer Vertrauenskette. Fehlerhafte Signaturen führen zur Ablehnung. Korrekt als unsigniert erkannte Zonen bleiben nutzbar, erhalten aber keine kryptografisch bestätigte Echtheit. DNSSEC verschlüsselt keine Anfragen.

2. Beispiel für Debian oder Raspberry Pi OS

Das Beispiel setzt Pi-hole und Unbound auf demselben Host ohne getrennte Container-Netze voraus. Änderungen an einem verwendeten DNS-Dienst können die Namensauflösung unterbrechen; eine Sicherung der bisherigen Konfiguration und ein erreichbarer Verwaltungszugang gehören zur Vorbereitung. Ausgehendes UDP und TCP auf Port 53 müssen für die Rekursion verfügbar sein.

Installation aus den gepflegten Distributionspaketen:

sudo apt update
sudo apt install unbound dnsutils

Vor einer zusätzlichen Konfiguration ist die Paketkonfiguration unter /etc/unbound/ zu prüfen. Debian-Pakete richten üblicherweise Root-Hints und den DNSSEC-Vertrauensanker bereits ein. Ein vorhandenes auto-trust-anchor-file darf nicht nochmals für dieselbe Datei eingetragen werden. Der Unbound-Dienst braucht Schreibzugriff auf den automatisch gepflegten Anker. Fehlt diese Einrichtung, ist zunächst die Anleitung des Distributionspakets maßgeblich.

Folgendes Fragment für /etc/unbound/unbound.conf.d/pi-hole.conf ergänzt diese Paketkonfiguration:

server:
    interface: 127.0.0.1
    port: 5335
    verbosity: 0
    do-ip4: yes
    do-ip6: no
    do-udp: yes
    do-tcp: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: no
    edns-buffer-size: 1232
    prefetch: yes
    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
    private-address: 169.254.0.0/16
    private-address: fc00::/7
    private-address: fe80::/10

do-ip6: no wählt hier IPv4 für den Transport; AAAA-Datensätze bleiben abfragbar. Bei funktionierender nativer IPv6-Anbindung kann yes sinnvoll sein. Das Fragment definiert bewusst keinen zweiten Vertrauensanker und ist keine eigenständige vollständige Konfiguration.

Erst nach erfolgreicher Konfigurationsprüfung folgt der Neustart. Die folgenden Zeilen sind nacheinander auszuführen; bei einem Fehler der ersten Prüfung ist der Neustart abzubrechen:

sudo unbound-checkconf
sudo systemctl restart unbound
systemctl is-enabled unbound
dig @127.0.0.1 -p 5335 fail01.dnssec.works
dig @127.0.0.1 -p 5335 dnssec.works +ad

Der erste DNS-Test soll SERVFAIL liefern, der zweite NOERROR mit ad im Flag-Feld. Ein einzelnes SERVFAIL beweist keine funktionierende Validierung: Auch Verbindungsfehler können diese Antwort verursachen. Eine korrekte Systemzeit ist für DNSSEC erforderlich. restart aktiviert keinen Autostart; is-enabled prüft den bestehenden Zustand.

3. Pi-hole verbinden und den tatsächlichen Weg prüfen

Unter Settings > DNS wird 127.0.0.1#5335 als benutzerdefinierter Upstream eingetragen. Für ausschließlich lokale Rekursion werden andere Upstreams entfernt. Nach dem Speichern sollte eine Testabfrage an Pi-hole im Abfrageprotokoll Unbound als Weiterleitungsziel zeigen. Bei getrennten Containern bezeichnet 127.0.0.1 jeweils den eigenen Container; dort ist diese Adresse ungeeignet.

Die Option Use DNSSEC aktiviert zusätzliche Validierung in Pi-hole und ist keine bloße Weitergabe von Statusflags. Unbound validiert bereits unabhängig davon. Falls die zusätzliche Prüfung aktiviert wird, sind beide DNSSEC-Tests nochmals über Pi-hole auszuführen. Vorhandene openresolv– oder unbound-resolvconf-Integration benötigt ebenfalls Kontrolle: Ein Eintrag für Port 53 darf keine Schleife zum lokalen Dienst erzeugen.

4. DoH als andere Betriebsart

Bei direkter Rekursion verlassen gewöhnliche DNS-Anfragen das Netz unverschlüsselt. QNAME-Minimierung reduziert die Namensteile, die einzelne Server erhalten; ein Beobachter auf der Internetleitung kann weiterhin Anfragen mitlesen.

Ein bewusst eingerichteter DoH-Upstream verschlüsselt die Verbindung zu einem gewählten Resolver. Dieser Resolver erhält die weitergeleiteten Namen. Das ist eine andere Architektur, kein automatisch vorhandener Rückfallmodus. Ein zusätzlicher Pi-hole-Upstream ist auch keine garantierte Reihenfolge für Ausfälle. Zertifikatsprüfung, Bootstrap-Auflösung und das Verhalten bei Nichterreichbarkeit benötigen eine eigene Konfiguration.

cloudflared proxy-dns wurde ab Version 2026.2.0 entfernt und ist keine aktuelle Installationsoption. Unbounds dokumentierte DoH-Unterstützung für eingehende Client-Abfragen ist außerdem von ausgehender DoH-Weiterleitung zu unterscheiden.