Unbound und Pi-hole: Dein eigener, sicherer DNS-Server

Mit Unbound und Pi-hole bauen Sie sich einen eigenen, sicheren DNS-Server, der Werbung und Tracking im Heimnetz blockiert und gleichzeitig DNS-Anfragen rekursiv und möglichst datensparsam auflöst. Das ist mehr als „nur Adblock“: Pi-hole übernimmt die Filterlogik (Blocklisten, lokale DNS-Einträge, Statistiken), während Unbound als rekursiver Resolver direkt bei den autoritativen Nameservern nachfragt – ohne dass ein öffentlicher DNS-Anbieter Ihre kompletten Domain-Anfragen als Profil sehen muss. Richtig konfiguriert profitieren Sie von mehr Kontrolle, häufig auch von schnelleren Antworten durch lokales Caching und von zusätzlicher Integrität durch DNSSEC-Validierung. Gleichzeitig gibt es ein paar Stolpersteine, die viele Setups unnötig instabil machen: falsche Port-Konflikte, zu große DNS-Pakete, ein fehlender „Safe“-Betrieb bei IPv6, unklare Router-Einstellungen oder ein zu aggressives Logging, das SD-Karten auf Dauer verschleißt. Dieser Artikel führt Sie strukturiert durch die wichtigsten Entscheidungen und Einstellungen – von der Hardware- und Systembasis über die Installation bis hin zu Hardening, Performance-Tuning und typischen Fehlerszenarien. So entsteht ein DNS-Stack, der im Alltag zuverlässig läuft, leicht zu warten ist und Ihren Geräten im Netzwerk eine zentrale, sichere Namensauflösung bietet.

Warum Pi-hole allein nicht „maximale DNS-Privatsphäre“ bedeutet

Pi-hole wird oft als netzwerkweiter Werbeblocker beschrieben – und genau das ist es auch. Standardmäßig agiert Pi-hole jedoch als DNS-Forwarder: Es nimmt DNS-Anfragen Ihrer Geräte an und leitet sie an einen Upstream-DNS weiter (z. B. den Router, den Provider oder einen öffentlichen Resolver). Damit blockieren Sie zwar Domains, aber Ihre nicht-blockierten Anfragen landen weiterhin bei einem externen Resolver. Unbound ändert genau diesen Teil: Statt weiterzuleiten, löst Unbound rekursiv auf. Das bedeutet, Unbound fragt schrittweise Root-, TLD- und autoritative Nameserver ab und baut Antworten selbst auf.

• Pi-hole: Filtert Domains, verwaltet Blocklisten, bietet ein Webinterface und lokale DNS-Funktionen.
• Unbound: Rekursiver, validierender und cachdender Resolver, der Anfragen selbst im DNS „nachverfolgt“.
• Kombination: Pi-hole bleibt die zentrale Anlaufstelle, Unbound wird der lokale, vertrauenswürdige Upstream.

Die offizielle, praxisnahe Anleitung der Pi-hole-Dokumentation ist ein sehr guter Referenzpunkt: Unbound als rekursiver Resolver in Pi-hole.

Was „sicherer DNS-Server“ in der Praxis bedeutet

„Sicher“ ist beim DNS mehrdimensional. Viele denken zuerst an Verschlüsselung (DoH/DoT), aber mindestens ebenso wichtig sind Integrität (DNSSEC), Minimierung unnötiger Daten (Privacy by Design) und ein sauberer Betrieb ohne offene Rekursion ins Internet. Mit Unbound und Pi-hole erreichen Sie typischerweise:

• Weniger Datenabfluss: Kein zentraler öffentlicher Resolver, der alle Domains Ihrer Geräte sieht.
• DNSSEC-Validierung: Schutz vor manipulierten Antworten, sofern Domains DNSSEC korrekt nutzen.
• Caching: Schnellere Antworten bei wiederholten Anfragen, weniger Last im Netz.
• Zentrale Kontrolle: Einheitliche DNS-Regeln für alle Geräte, inklusive IoT und Smart-TV.
• Saubere Segmentierung: Lokale Hostnames, Split-DNS und feste Zuordnungen im Heimnetz.

Wichtig: Ein lokaler rekursiver Resolver ersetzt nicht automatisch Verschlüsselung „auf der Leitung“. Rekursion bedeutet primär mehr Kontrolle und weniger Abhängigkeit. Verschlüsselung zu externen Resolvers ist ein anderes Konzept und kann alternativ über DoH/DoT-Lösungen ergänzt werden.

Voraussetzungen: Hardware, Betriebssystem und Netzwerkgrundlagen

Für Unbound und Pi-hole reichen bereits kleine Raspberry-Pi-Modelle, solange die Stromversorgung stabil und der Datenträger zuverlässig ist. In deutschen Heimnetzen ist außerdem die Router-Integration (häufig FRITZ!Box oder vergleichbare Geräte) entscheidend, weil DNS-Server im DHCP verteilt werden.

• Hardware: Raspberry Pi 3, 4 oder 5 funktionieren sehr gut. Für reine DNS-Aufgaben ist auch ein Pi Zero 2 W möglich, Ethernet ist aber meist stabiler als WLAN.
• Datenträger: Eine hochwertige microSD oder besser SSD (bei intensiver Nutzung und viel Logging).
• OS: Ein aktuelles Debian-basiertes System (z. B. Raspberry Pi OS). Updates sind wichtig, um Sicherheitsfixes zu erhalten.
• Netzwerk: Feste IP-Adresse oder DHCP-Reservierung für den Pi; ansonsten „wandert“ der DNS-Server im Netz.

Wenn Sie Pi-hole noch nicht installiert haben, orientieren Sie sich an der offiziellen Installationsdokumentation: Pi-hole Installation.

Architektur: So sprechen Ihre Geräte mit Pi-hole und Unbound

Ein bewährtes Setup sieht so aus: Ihre Endgeräte verwenden Pi-hole als einzigen DNS-Server. Pi-hole wiederum nutzt Unbound als „Custom Upstream“ auf dem lokalen Gerät, typischerweise auf einem separaten Port (klassisch 5335), damit es keinen Konflikt mit dem Pi-hole-DNS-Dienst gibt. Unbound hört also nicht auf Port 53, sondern nur lokal auf einem alternativen Port, und Pi-hole leitet Anfragen dorthin weiter.

• Clients: DNS = IP des Pi-hole (Port 53).
• Pi-hole: Filtert und leitet erlaubte Anfragen an Unbound (z. B. 127.0.0.1:5335).
• Unbound: Rekursiv + Cache + DNSSEC, nur lokal erreichbar.

Diese Trennung ist gleichzeitig ein Sicherheitsmerkmal: Unbound sollte nicht als „offener Resolver“ für das Internet erreichbar sein.

Installation von Unbound: Grundprinzip und saubere Einbindung

Unbound wird auf dem gleichen System installiert, auf dem Pi-hole läuft. Anschließend wird eine Unbound-Konfiguration angelegt, die speziell für den lokalen Betrieb ausgelegt ist: nur lokale Schnittstellen, separater Port, sinnvolle Privacy- und Hardening-Optionen. Die Pi-hole-Dokumentation beschreibt diesen Weg sehr kompakt und praxiserprobt: Pi-hole Guide: Unbound. Für Details zu Parametern lohnt sich die offizielle Unbound-Dokumentation von NLnet Labs: Unbound Dokumentation.

• Port-Konzept: Unbound lokal auf einem alternativen Port, Pi-hole bleibt auf 53.
• Bindung: Unbound idealerweise nur auf 127.0.0.1 bzw. localhost, nicht auf allen Interfaces.
• DNSSEC: Validierung aktivieren, Trust Anchor sauber verwalten.
• Logging: Nicht übertreiben, um Speicher und SD-Karte zu schonen.

Pi-hole korrekt konfigurieren: Unbound als Upstream Resolver

In Pi-hole tragen Sie Unbound als benutzerdefinierten Upstream-DNS-Server ein. Üblich ist „127.0.0.1#5335“ (lokal) oder „::1#5335“ (IPv6 localhost), abhängig von Ihrer Konfiguration. Danach sollten Sie in den Pi-hole-Einstellungen andere Upstream-Resolver deaktivieren, wenn Sie konsequent rekursiv auflösen möchten. So stellen Sie sicher, dass Pi-hole nicht „heimlich“ wieder auf öffentliche Resolver ausweicht.

• Nur ein Upstream: Unbound als einziger Upstream reduziert Fehlerquellen und erhöht Transparenz.
• Fallback vermeiden: Wenn Unbound ausfällt, fällt DNS im Heimnetz aus – planen Sie daher Stabilität oder Redundanz.
• Lokale DNS-Einträge: Pi-hole bleibt ideal, um Geräte im Heimnetz sauber zu benennen und zu finden.

DNSSEC, Hardening und Privacy-Optionen: So wird Unbound „sicher“

Ein rekursiver Resolver sollte nicht nur „funktionieren“, sondern auch möglichst robuste Defaults haben. Dazu gehören DNSSEC-Validierung, das Verbergen von Versionsinformationen und sinnvolle Limits, um Missbrauch und Fehlkonfigurationen zu vermeiden. Unbound bietet dafür zahlreiche Optionen. Achten Sie insbesondere auf:

• DNSSEC-Validierung: Damit erkennt Unbound signierte Zonen und kann Manipulationen erschweren.
• QNAME-Minimisation: Reduziert, welche Informationen Unbound an übergeordnete Nameserver weitergibt (Privacy-Aspekt).
• Harden-Optionen: Einstellungen wie „harden-glue“ oder „harden-dnssec-stripped“ (je nach Dokumentation) können die Resolver-Integrität verbessern.
• Identity/Version verstecken: Weniger Fingerprinting im lokalen Netz.
• Zugriff beschränken: Nur lokale Clients zulassen, keine offene Rekursion.

Wenn Sie Parameter genauer verstehen möchten, ist die offizielle Unbound-Dokumentation der richtige Ort: Unbound by NLnet Labs.

EDNS, Fragmentierung und warum „1232“ in vielen Setups auftaucht

Ein verbreitetes Problem bei DNS-Setups im Heimnetz sind zu große UDP-DNS-Pakete, die durch Fragmentierung oder Path-MTU-Probleme verloren gehen. Das äußert sich als „manche Domains laden nicht“ oder sporadische Timeouts. Besonders in Kombination mit DNSSEC (größere Antworten) kann das auffallen. Viele praxiserprobte Setups begrenzen daher die maximale UDP-Paketgröße für EDNS, um Fragmentierung zu vermeiden. Der Wert 1232 wird häufig verwendet, weil er in vielen Netzen als „sicherer“ Kompromiss gilt.

• Symptom: Einzelne Dienste funktionieren nicht, während andere problemlos laufen.
• Ursache: Große DNS-Antworten werden fragmentiert und gehen unterwegs verloren.
• Lösung: EDNS-Paketgröße begrenzen und/oder TCP-Fallback zuverlässig aktivieren.

Die Pi-hole-Unbound-Anleitung erwähnt diesen Themenkomplex in der Praxis oft explizit: Unbound Guide in der Pi-hole Doku.

Performance-Tuning: Cache, Prefetch und sinnvolle Limits

Unbound kann DNS-Anfragen durch Caching deutlich beschleunigen, insbesondere bei wiederkehrenden Domains (Apps, Updateserver, Streaming, Smart-Home). Gleichzeitig sollten Sie Cache und Threads nicht „blind“ maximieren. Ein Raspberry Pi läuft stabil, wenn die Konfiguration zum Einsatzzweck passt. Typische Optimierungsprinzipien:

• Cache-Größen angemessen wählen: Nicht jeder Pi braucht riesige Caches, aber ein zu kleiner Cache verschenkt Performance.
• Prefetch nutzen: Häufig angefragte Einträge können im Hintergrund erneuert werden, bevor sie ablaufen.
• Logging reduzieren: Debug-Logs nur bei Problemen aktivieren, sonst unnötige Schreiblast.
• WLAN vermeiden: Wenn möglich, Pi per Ethernet betreiben; DNS reagiert sensibel auf Paketverluste.

Redundanz und Ausfallsicherheit: Zweiter Pi-hole oder smarter Router?

DNS ist eine Kernfunktion im Netzwerk. Wenn Ihr Pi ausfällt, wirkt das schnell wie ein „Internet-Ausfall“. In Haushalten mit hohem Anspruch (Homeoffice, Smart-Home, viele Geräte) lohnt sich Redundanz. Das kann bedeuten:

• Zweiter Pi-hole: Ein zweites Gerät als Backup-DNS, idealerweise ebenfalls mit eigenem Unbound.
• DNS im Router nicht überfrachten: Viele Router sind als DNS-Server funktionsfähig, aber selten so transparent und flexibel wie Pi-hole.
• DHCP-Konzept: Zwei DNS-Server im DHCP verteilen, damit Clients beim Ausfall wechseln können.

Beachten Sie: Zwei rekursive Resolver sind nicht „doppelt so schnell“, aber deutlich robuster, wenn Wartung oder Updates anstehen.

Unbound vs. DoH/DoT: Was ist „privater“ und was ist „sicherer“?

Unbound als rekursiver Resolver reduziert die Abhängigkeit von einem einzelnen öffentlichen DNS-Dienst, aber Ihre Abfragen zu autoritativen Nameservern sind weiterhin klassisches DNS (meist unverschlüsselt). DoH/DoT verschlüsselt dagegen den Transport zu einem Upstream-Anbieter, der dann rekursiv für Sie auflöst. Beides hat Vor- und Nachteile:

• Unbound (rekursiv): Mehr Kontrolle, weniger zentrale Datenaggregation, DNSSEC möglich; Transport zu vielen Servern, klassisches DNS im Internet.
• DoH/DoT (forwarding): Verschlüsselter Transport zu einem Anbieter; dafür sieht dieser Anbieter Ihre Anfragen konzentriert.
• Praxis im Heimnetz: Wer maximale Unabhängigkeit will, nutzt Unbound; wer Transportverschlüsselung priorisiert, nutzt DoH/DoT über einen Proxy.

Wenn Sie DoH mit Pi-hole umsetzen möchten, beschreibt Pi-hole das Vorgehen mit cloudflared ausführlich: cloudflared (DoH) in der Pi-hole Doku.

Typische Fehlerbilder und schnelle Diagnose

Die häufigsten Probleme lassen sich meist schnell eingrenzen, wenn Sie systematisch vorgehen: Zuerst prüfen, ob Pi-hole DNS ausliefert, dann ob Unbound erreichbar ist, und zuletzt, ob Rekursion und DNSSEC stabil funktionieren.

• Keine Namensauflösung im ganzen Netz: Pi-hole-IP im DHCP falsch, Pi offline, Port 53 blockiert oder Clients nutzen weiterhin den Router-DNS.
• Pi-hole zeigt Anfragen, aber Antworten fehlen: Unbound nicht erreichbar (Port/Bind), Firewall-Regeln, falscher Upstream-Eintrag in Pi-hole.
• Nur manche Domains schlagen fehl: EDNS/MTU-Probleme, DNSSEC große Antworten, instabiles WLAN.
• Langsame erste Abfragen, danach schnell: Normaler Cache-Effekt; bei dauerhaft langsam: CPU-Last, SD-Probleme oder Upstream/Netzwerkqualität prüfen.
• IPv6-Probleme: Router verteilt IPv6-DNS anders als IPv4; Clients umgehen Pi-hole über IPv6.

IPv6 im deutschen Heimnetz: Der häufig unterschätzte Umgehungsweg

Gerade in Deutschland ist IPv6 oft aktiv, teils automatisch über den Router. Das ist grundsätzlich gut, kann aber Pi-hole-Setups umgehen, wenn Clients per IPv6 andere DNS-Server erhalten. Achten Sie daher darauf, dass Ihr Netzwerk sowohl für IPv4 als auch IPv6 konsistent Pi-hole als DNS verteilt. In Pi-hole selbst sollten Sie IPv6 bewusst aktivieren oder deaktivieren – halbherzige Mischzustände führen häufig zu schwer zu diagnostizierenden Effekten.

• DHCPv6/RA prüfen: Der Router verteilt DNS-Infos oft über Router Advertisements.
• Pi-hole IPv6 konfigurieren: Wenn IPv6 im Netz genutzt wird, sollte Pi-hole sauber erreichbar sein.
• Testen: Ein Gerät bewusst nur über IPv6 prüfen, ob es weiterhin über Pi-hole auflöst.

Wartung und Updates: Stabil bleiben, ohne ständig „alles neu“ zu machen

Ein eigener DNS-Server ist Infrastruktur. Das bedeutet: Updates sind wichtig, aber sollten kontrolliert erfolgen. Planen Sie Wartungsfenster, nutzen Sie Backups und behalten Sie die SD-Karte im Blick. Häufige Best Practices:

• Regelmäßige Updates: Pi-hole und Systempakete aktuell halten, Sicherheitslücken vermeiden.
• Konfigurationssicherung: Pi-hole-Settings exportieren und Unbound-Konfigurationsdateien sichern.
• Blocklisten mit Maß: Zu viele Listen erhöhen Pflegeaufwand und False Positives, ohne zwingend mehr Nutzen zu bringen.
• Monitoring: DNS-Fehlerquoten und Latenzen im Blick behalten, bevor Nutzer „Internet kaputt“ melden.

Weiterführende Informationsquellen (Outbound-Links)

• Pi-hole: Unbound als rekursiver DNS-Resolver
• Pi-hole: Offizielle Installation
• Unbound Dokumentation (NLnet Labs)
• Unbound Projekt auf GitHub
• Pi-hole: DNS over HTTPS mit cloudflared

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.