Pi-hole mit Unbound: Werbefilter plus eigener rekursiver DNS

Pi-hole blockt Werbung und Tracker im ganzen Netz — aber die eigentliche Namensauflösung reicht es nur weiter: an Google (8.8.8.8), Cloudflare (1.1.1.1) oder deinen Provider. Wer Selfhosting ernst meint, holt sich auch diesen Schritt ins Haus: Unbound als rekursiver Resolver fragt die DNS-Root-Server direkt — kein Dritter sieht mehr deine gesammelte DNS-Historie.

Wie die Kette danach aussieht

Client → Pi-hole (filtert Werbung/Tracker)
            → Unbound (löst rekursiv auf, validiert DNSSEC)
                → Root- / TLD- / autoritative Server

Bonus nebenbei: Unbound validiert DNSSEC und cached aggressiv — nach kurzer „Aufwärmphase“ sind häufige Domains oft schneller beantwortet als über einen externen Forwarder.

Schritt 1: Unbound installieren

Auf demselben Gerät wie Pi-hole (Raspberry Pi, LXC, VM — egal):

sudo apt install unbound

Schritt 2: Unbound-Konfiguration für Pi-hole

Die Konfiguration als eigene Datei anlegen — /etc/unbound/unbound.conf.d/pi-hole.conf:

server:
    verbosity: 0
    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # IPv6 aktivieren, wenn dein Anschluss es sauber kann
    do-ip6: no
    prefer-ip6: no

    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: no
    edns-buffer-size: 1232

    prefetch: yes
    num-threads: 1
    so-rcvbuf: 1m

    # Private Adressbereiche nie aus öffentlichen Antworten akzeptieren
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

Dann neu starten und testen:

sudo service unbound restart
dig labkompass.de @127.0.0.1 -p 5335

Die Antwort sollte status: NOERROR zeigen. DNSSEC-Gegenprobe: dig dnssec-failed.org @127.0.0.1 -p 5335 muss mit SERVFAIL abgelehnt werden — genau das ist das gewünschte Verhalten.

Schritt 3: Pi-hole auf Unbound umstellen

In der Pi-hole-Oberfläche unter Settings → DNS:

Alle vorausgewählten Upstream-Server (Google, Cloudflare …) abwählen
Bei Custom DNS eintragen: 127.0.0.1#5335
Speichern

Ab jetzt läuft jede nicht gecachte Anfrage über deinen eigenen Resolver. Prüfen kannst du das im Query Log: Als Upstream steht nun 127.0.0.1#5335.

Schritt 4: Der Rest des Netzes

Damit alle Geräte den Pi-hole nutzen, trägst du ihn als DNS-Server im DHCP ein — je nach Setup:

FritzBox: Heimnetz → Netzwerk → Netzwerkeinstellungen → IPv4 → Lokaler DNS-Server auf die Pi-hole-IP setzen. Details und Fallstricke (Stichwort DNS-Rebind-Schutz) behandeln wir im FritzBox-Cluster.
OPNsense: Im DHCP der jeweiligen Netze den Pi-hole als DNS ausliefern — oder Unbound gleich direkt auf der OPNsense betreiben; dann übernimmt die Firewall beide Rollen.

Häufige Fragen und Stolperfallen

„Ist rekursives DNS langsamer?“ Die allererste Anfrage an eine Domain: ja, minimal (mehrere Nachfragen statt einer). Danach übernimmt der Cache. Im Alltag nicht spürbar.
Port 5335 statt 53: Absicht — auf 53 lauscht ja bereits Pi-hole. Unbound ist bewusst nur lokal (127.0.0.1) erreichbar.
unbound-control meldet Fehler / Logs voller Timeouts: Häufig blockt die Firewall ausgehende DNS-Anfragen (TCP/UDP 53) des Servers — Unbound muss selbst hinaus dürfen.
Router verteilt sich weiterhin selbst als DNS: Dann tauchen Geräte im Pi-hole nur als „Router“ auf. Für saubere Statistiken muss der DHCP die Pi-hole-IP direkt ausliefern.
Zweiter Pi-hole: DNS ist kritische Infrastruktur — fällt der einzige Pi-hole aus, „ist das Internet kaputt“ (für die Familie jedenfalls). Ein zweiter Pi-hole (z. B. als LXC auf dem Proxmox-Host) als sekundärer DNS ist der übliche Weg.

Fazit

Pi-hole + Unbound ist eines der dankbarsten Selfhosting-Projekte überhaupt: eine halbe Stunde Aufwand, danach filtert und löst dein Netz vollständig selbst auf — schneller Cache, DNSSEC-Validierung und keine DNS-Historie mehr bei Dritten.