Pi-hole blockiert Werbung, Tracking-Domains und unerwünschte DNS-Anfragen im eigenen Netzwerk. Standardmäßig leitet Pi-hole erlaubte DNS-Anfragen an einen externen DNS-Resolver weiter, etwa Cloudflare, Quad9 oder Google DNS. Eine Alternative ist Unbound.

Unbound arbeitet als rekursiver, validierender und cachingfähiger DNS-Resolver. Statt DNS-Anfragen an einen einzelnen öffentlichen Anbieter weiterzugeben, fragt Unbound die DNS-Hierarchie selbst ab: Root-Server, TLD-Server und schließlich autoritative Nameserver. Antworten werden lokal zwischengespeichert und können per DNSSEC validiert werden.

Warum Pi-hole mit Unbound kombinieren?

• Weniger Abhängigkeit von öffentlichen DNS-Anbietern: DNS-Anfragen werden nicht gesammelt an einen zentralen Resolver-Dienst weitergereicht.
• Lokaler DNS-Cache: Bereits abgefragte Domains können bei erneuten Anfragen schneller beantwortet werden.
• DNSSEC-Validierung: Unbound kann fehlerhafte oder manipulierte DNS-Antworten erkennen und verwerfen.
• Klare Aufgabenverteilung: Pi-hole filtert, Unbound löst DNS-Anfragen auf.

Nachteile und Stolpersteine

Die Kombination aus Pi-hole und Unbound ist sinnvoll, aber nicht automatisch in jeder Situation schneller oder einfacher.

• Erste Abfragen können länger dauern: Große öffentliche Resolver besitzen sehr große, bereits gefüllte Caches. Ein lokaler rekursiver Resolver muss unbekannte Domains zunächst selbst auflösen.
• Direkte DNS-Kommunikation muss funktionieren: Der Server muss DNS-Anfragen zu Root- und autoritativen Nameservern selbst stellen können. Einschränkungen durch Router, Provider oder Firewalls können Probleme verursachen.
• Port-Konflikte vermeiden: Pi-hole benötigt Port 53 auf dem Host. Unbound sollte in einem Docker-Setup in der Regel nur intern im Docker-Netzwerk erreichbar sein.
• Docker-Image bewusst wählen: Für Unbound wird häufig das Community-Image mvance/unbound verwendet. Bei produktiven Setups lohnt sich ein Blick auf die tatsächlich aktive Konfiguration.

Beispielarchitektur

Clients
  │
  ▼
Pi-hole
  │
  ▼
Unbound
  │
  ▼
DNS-Hierarchie im Internet

Im folgenden Beispiel laufen Pi-hole und Unbound als getrennte Docker-Container im selben Docker-Netzwerk.

Ordnerstruktur

dns-stack/
├── compose.yml
└── pihole/
    └── etc-pihole/

Docker-Compose-Konfiguration

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    restart: unless-stopped
    hostname: pihole
    networks:
      - dns_net
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8080:80/tcp"
    environment:
      TZ: Europe/Berlin
      FTLCONF_webserver_api_password: "bitte-aendern"
      FTLCONF_dns_upstreams: "unbound#53"
    volumes:
      - ./pihole/etc-pihole:/etc/pihole

  unbound:
    container_name: unbound
    image: mvance/unbound:latest
    restart: unless-stopped
    networks:
      - dns_net

networks:
  dns_net:
    driver: bridge

Entscheidend ist diese Zeile im Pi-hole-Container:

FTLCONF_dns_upstreams: "unbound#53"

Damit verwendet Pi-hole den Container mit dem Namen unbound als DNS-Upstream. Wichtig: In einem Docker-Netzwerk verweist unbound auf den gleichnamigen Container. 127.0.0.1 wäre an dieser Stelle falsch, weil sich Pi-hole und Unbound in getrennten Containern befinden.

Container starten

docker compose up -d

Danach lässt sich der Status prüfen:

docker compose ps

Prüfen, ob Unbound erreichbar ist

Aus dem Pi-hole-Container heraus kann eine direkte DNS-Abfrage an Unbound gestellt werden:

docker exec -it pihole dig example.org @unbound -p 53

Eine erfolgreiche Ausgabe enthält typischerweise eine Antwortsektion und verweist beim DNS-Server auf den Unbound-Container.

;; SERVER: 172.x.x.x#53(unbound)

Prüfen, ob Pi-hole Unbound wirklich nutzt

Die gesetzte Upstream-Konfiguration lässt sich direkt im Pi-hole-Container prüfen:

docker exec -it pihole pihole-FTL --config dns.upstreams

Erwartet wird:

unbound#53

Zusätzlich kann eine DNS-Abfrage direkt über Pi-hole ausgelöst werden:

docker exec -it pihole dig example.org @127.0.0.1 -p 53

Damit wird der vollständige Weg getestet:

Pi-hole → Unbound → Internet

DNSSEC-Funktion testen

Ob DNSSEC-Validierung funktioniert, lässt sich mit bekannten Testdomains prüfen:

docker exec -it pihole dig sigok.verteiltesysteme.net @unbound -p 53
docker exec -it pihole dig sigfail.verteiltesysteme.net @unbound -p 53

Erwartetes Verhalten:

• sigok... liefert eine normale DNS-Antwort.
• sigfail... endet mit SERVFAIL.

Performance grob bewerten

Ein einfacher Test besteht darin, dieselbe Domain zweimal direkt über Unbound abzufragen:

docker exec -it pihole dig example.org @unbound -p 53
docker exec -it pihole dig example.org @unbound -p 53

Die erste Anfrage ist häufig langsamer, weil Unbound rekursiv auflösen muss. Die zweite Anfrage sollte meist deutlich schneller beantwortet werden, da der Cache greift.

Als grobe Orientierung:

• Erste Abfrage: einige Dutzend bis wenige hundert Millisekunden können normal sein.
• Wiederholte Abfrage: häufig nur wenige Millisekunden.

Typische Fehlerbilder

Unbound antwortet nicht

Mögliche Ursachen:

• Der Container wurde nicht gestartet.
• Pi-hole und Unbound befinden sich nicht im selben Docker-Netzwerk.
• Der Containername stimmt nicht mit unbound#53 überein.

Hilfreiche Prüfkommandos:

docker logs unbound
docker logs pihole

Pi-hole nutzt nicht den gewünschten Resolver

Dann sollte erneut kontrolliert werden, ob der Upstream korrekt gesetzt ist:

docker exec -it pihole pihole-FTL --config dns.upstreams

Port 53 ist bereits belegt

Pi-hole benötigt Port 53 auf dem Host für DNS-Anfragen aus dem Netzwerk. Läuft dort bereits ein anderer DNS-Dienst, muss dieser deaktiviert oder die Umgebung angepasst werden.

Fazit

Pi-hole in Kombination mit Unbound ist eine robuste Lösung für alle, die DNS-Filterung und mehr Kontrolle über die eigene Namensauflösung miteinander verbinden möchten. Die Architektur reduziert die Abhängigkeit von öffentlichen DNS-Resolvern, ermöglicht DNSSEC-Validierung und bietet durch lokales Caching im Alltag häufig gute Antwortzeiten.

Man sollte die Lösung dennoch nüchtern bewerten: Rekursive DNS-Auflösung ist beim ersten Zugriff nicht zwingend schneller als große öffentliche Resolver, und die Docker-Konfiguration muss sauber umgesetzt werden. Wer diese Punkte berücksichtigt, erhält jedoch ein gut nachvollziehbares und leistungsfähiges DNS-Setup.

Ergänzender Artikel: Netzwerkfilter mit piHole