Pi-hole ist schnell installiert. Die eigentliche Arbeit beginnt danach: Geräte müssen weiterhin DNS auflösen, Home Assistant darf nicht plötzlich als „kaputt“ erscheinen und ein Ausfall des Pi-hole-Hosts darf nicht das ganze Zuhause vom Netz nehmen.
Mein klares Urteil: Pi-hole ist ein guter Filter, aber kein magischer Sicherheitsknopf. Wer DNS sauber plant und die Warnungen versteht, bekommt mehr Privatsphäre ohne sich bei jedem kleinen Fehler selbst aus dem Netzwerk zu schießen.
Der grundlegende Einstieg bleibt mein Pi-hole-DNS-Artikel für Smart Home und Privatsphäre. Dieser Folgebeitrag konzentriert sich auf die Diagnose danach.
Was Pi-hole im Netzwerk tatsächlich macht
Pi-hole beantwortet DNS-Anfragen für Geräte im lokalen Netz und kann bekannte Werbe- und Tracking-Domains blockieren. Es sitzt damit an einer wichtigen, aber klar begrenzten Stelle:
- Pi-hole filtert DNS-Anfragen.
- Der Router verteilt normalerweise die DNS-Adresse an die Clients.
- Home Assistant nutzt DNS für Integrationen, Updates und externe Dienste.
- Webseiten, Apps und Geräte können trotzdem eigene DoH-/DoT-Wege oder fest verdrahtete Resolver verwenden.
Das erklärt, warum ein sauberer Pi-hole-Status nicht bedeutet, dass jede Werbung verschwindet. Umgekehrt bedeutet eine Warnung nicht automatisch, dass Pi-hole komplett falsch eingerichtet ist.
Die drei häufigsten DNS-Warnungen
1. Der Client nutzt nicht Pi-hole
Wenn ein Gerät im Pi-hole-Dashboard nicht auftaucht, fragt es wahrscheinlich einen anderen Resolver. Häufige Ursachen:
- der Router verteilt weiterhin den Provider-DNS
- ein Gerät verwendet einen manuell eingetragenen DNS-Server
- ein VPN oder ein Browser übernimmt die Namensauflösung
- IPv6 verteilt einen anderen DNS-Pfad als IPv4
Der erste Check ist deshalb nicht die Blockliste, sondern die Frage: Welche DNS-Adresse verwendet der betroffene Client wirklich?
2. Pi-hole ist erreichbar, aber nicht der einzige Resolver
Ein zweiter DNS-Server klingt zunächst wie ein Fallback. In der Praxis kann das aber dazu führen, dass manche Anfragen Pi-hole umgehen. Dann wirken Blockraten und Geräteverhalten zufällig.
Ich würde zuerst eine klare primäre DNS-Adresse verteilen und erst danach über einen echten Ausfallpfad nachdenken. Zwei gleichberechtigte Resolver sind kein Ersatz für eine getestete Hochverfügbarkeit.
3. Der DNS-Host ist selbst nicht stabil
Wenn Pi-hole in einem Container oder auf einem kleinen Mini-PC läuft, zählen die unspektakulären Dinge:
- feste IP oder DHCP-Reservierung
- stabile Stromversorgung
- funktionierender Autostart
- erreichbare Weboberfläche im LAN
- dokumentierter Weg zurück zum Router-DNS
Im lokalen Reproduktionstest für diesen Folgebeitrag antwortete der aktive Resolver 10.10.34.1; auch der lokale Stub 127.0.0.53 sowie 1.1.1.1 und 8.8.8.8 lösten example.com auf. Das beweist aber nur, dass Namensauflösung funktioniert. Es beweist nicht, dass ein bestimmter Client Pi-hole nutzt. In einer echten Pi-hole-Installation muss deshalb zusätzlich das Query-Log die Anfrage zeigen. Eine ausführbare Kurzfassung des Tests liegt im lokalen Arbeitsprotokoll.
Für einen schnellen Gegencheck auf Linux kannst du genau diesen Ablauf verwenden:
resolvectl status
dig +time=2 +tries=1 +short @127.0.0.53 example.com
dig +time=2 +tries=1 +short @1.1.1.1 example.com
dig +time=2 +tries=1 +short @8.8.8.8 example.com
Auf Windows sind nslookup example.com und nslookup example.com 1.1.1.1 das passende Gegenstück. Entscheidend ist nicht, ob irgendein Resolver antwortet, sondern ob der Client den gewünschten lokalen Resolver verwendet und die Anfrage im Pi-hole-Query-Log auftaucht.
Meine Prüf-Reihenfolge bei einer Warnung
Ich würde nicht sofort Blocklisten wechseln oder den Container neu installieren. Die Reihenfolge ist wichtiger:
- Pi-hole-IP prüfen: Ist die Adresse im LAN erreichbar und unverändert?
- Client prüfen: Welche DNS-Server zeigt das Gerät tatsächlich?
- Namensauflösung testen: Löst der Client eine normale Domain auf?
- Pi-hole-Query-Log prüfen: Taucht die Anfrage dort auf?
- Router prüfen: Wird DNS per DHCP für IPv4 und IPv6 konsistent verteilt?
- Sonderwege ausschließen: VPN, Private Relay, DoH, manuelle DNS-Einträge.
- Erst danach Blocklisten oder Ausnahmen anpassen.
Diese Reihenfolge trennt Netzwerkfehler von Filterfehlern. Das spart Zeit und verhindert, dass du eine funktionierende Installation wegen des falschen Symptoms zerlegst.
Fallback ohne Chaos
Ein Fallback ist sinnvoll, aber er sollte bewusst geplant sein. Für ein kleines Zuhause würde ich zwei Szenarien unterscheiden:
Pi-hole fällt kurz aus
Dann sollte der Router oder ein zweiter lokaler Resolver die Namensauflösung übernehmen können. Wichtig ist, den Rückfall einmal zu testen und zu dokumentieren. Ein Fallback, den niemand kennt, ist nur Theorie.
Pi-hole filtert eine benötigte Domain
Dann gehört die Domain gezielt auf eine Allowlist. Nicht gleich die gesamte Blockliste deaktivieren. Vorher im Query-Log prüfen, welche Domain wirklich blockiert wurde und ob sie zum betroffenen Dienst gehört.
Was Pi-hole nicht ersetzt
Pi-hole ist kein Ersatz für:
- Router-Firewall und aktuelle Firmware
- sichere Passwörter und MFA
- Backups
- Endgeräteschutz
- VPN oder einen kontrollierten Fernzugriff
- eine saubere Netzwerksegmentierung
Für ein lokales Smart Home passt Pi-hole gut als zusätzliche Schicht. Wer mehr über die Gesamtarchitektur sucht, kann mit Smart Home ohne Cloud: ein günstiges lokales Setup und Home Assistant erste Schritte 2026 weiterarbeiten. Die Home-Assistant-Installation auf Proxmox hilft beim Infrastrukturteil.
Mein Fazit
Die wichtigste Pi-hole-Regel lautet: Erst den DNS-Pfad beweisen, dann die Filterung optimieren. Wenn die Anfrage nicht im Query-Log auftaucht, ist die Blockliste nicht dein Problem.
Für Einsteiger ist ein stabiler Pi-hole-Host mit klarer Router-Konfiguration besser als ein kompliziertes Multi-DNS-Konstrukt. Die Warnung darf ernst genommen werden, aber sie ist zunächst ein Diagnosehinweis — kein Beweis für eine kaputte Installation.
