I’m experiencing sporadic issues with Pi-hole on my Raspberry Pi 3B+ running Debian 12, along with UFW, PiVPN, and Unbound. Some domains that I’ve added to the whitelist in the Pi-hole web interface stop working after a while. They only work again after I restart the Raspberry Pi, and then the issue reoccurs after a few days. Additionally, I have problems with the Pi-hole admin interface when accessing it on my iPad (WiFi 13-inch, 2024). It shows an error message saying the address is invalid. However, when I click the reload button in Safari, the interface works again. Here is the link to the debug token: https://tricorder.pi-hole.net/EB2R4yFz/
For example, it works for a day and then I have to restart the Raspberry Pi, then it works again.
I get the following error message: Safari cannot open the page because the address is invalid.
I can't try the nslookup right now because the domain is currently working.
But I also have the problem that when I log in to the admin interface, I get the following error message: safari cannot open the page because the network connection was lost. However, the internet connection was never lost. When I press the reload button, I have to log in again and then it works.
If an address is already known, then that would indicate that DNS resolution has already succeeded in translating a domain into an IP address, suggesting a networking issue instead.
This also would suggest a networking rather than a DNS issue.
What prompts you to suspect that Pi-hole would be involved?
(On a side note: I noticed that you've closed a duplicate of your topic in the German category.
If you'd prefer, we could also continue in German.)
Ja, wir können gerne auf Deutsch weitermachen. Ich hatte es auf beiden Foren gepostet, weil es ja mehr englischsprachige Nutzer gibt, die mir eher helfen können nachdem ich dann hier eine Antwort erhalten habe, habe ich den andern Post gelöscht, damit es kein Doppelpost gibt.
Ich gehe davon aus, dass es sich um ein Problem mit Pi-hole handelt, weil wenn ich diesen abschalte, dann kann ich den Fehler nicht reproduzieren und bei der Domain um die es sich handelt, taucht auch in der vorkonfigurierten Liste von Pi-hole auf weshalb ich sie ja in die Whitelist gesetzt habe.
Hmm, für sporadisch auftretende Fehler wäre es durchaus normal, dass sie nicht reproduzierbar sind (sonst träten sie ja irgendwie regelmässig auf ).
Da die Fehlermeldungen recht deutlich auf Adress- und Netzwerk(verbindungs)probleme hinweisen, würde ich hier zunächst davon ausgehen, dass es sich um genau solche handelt.
Ein paar nslookups zum Zeitpunkt des fehlenden Zugriffs würden helfen, das weiter einzugrenzen, z.B.
nslookup pi.hole
nslookup <domain> 192.168.27.27
wobei Du <domain> durch die jeweils problematische Domäne ersetzt.
Dazu sollte es möglichst nicht nur von dem problematischen Rechner, sondern auch auf einem anderen ausgeführt werden, um zu prüfen, ob es sich vielleicht um ein client-spezifisches Problem handelt.
Zusätzlich wäre zum Zeitpunkt der Zugriffsschwierigkeiten ein Blick ins Query Log interessant, um zu sehen, ob und wie Pi-hole die problematische Domäne kurz zuvor aufgelöst hat.
Also ich konnte den Fehler jetzt nochmal reproduzieren und habe folgendes festgestellt: habe beide Befehle auf meinem iPad, iPhone und Windows Laptop eingegeben. Beim ersten Befehl bekomme ich überall die Ausgabe der IPs und beim zweiten Befehl bekomme ich eine nicht autorisierte Antwort mit den IPs 0.0.0.0 und :: und keiner der genutzten Clients (zusätzlich ein Android Gerät wo ich keine Befehle eingegeben habe) konnte die Seite aufrufen und jetzt ohne mein zu tun geht es plötzlich wieder. Im Query Log waren die Domain-Anfragen bei HTTPS, A und AAA mal grün und mal rot dabei war es egal von welchem Client ich aufgerufen habe.
<hh:m> dient dabei zur zeitlichen Eingrenzung auf eine bestimmte Stunde und 10-Minuten-Intervall, und <domain> ist wieder die entsprechende Domäne bzw. der Domänenanteil (also z.B. "Jan 12 07:1.*pi-hole.net", um alle Einträge für (*.)pi-hole.net von heute 07:10:00 bis 07:19:59 zu extrahieren).
Die Ausgabe zeigt, dass Pi-hole die DNS-Anfragen wie erwartet erlaubt und an Deinen Upstream-DNS-Server weiterleitet, dieser dann allerdings die 0.0.0.0 /::-Antworten liefert, in Deinem Fall unbound (forwarded ... to 127.0.0.1#5335, reply ... is 0.0.0.0).
Das wäre bei Konfiguration von unbound als rekursivem Resolver nicht zu erwarten.
Mit dieser Konfiguration läuft unbound nicht als rekursiver Resolver.
Vielmehr sieht das nach einem Versuch aus, unbound als DoT-Forwarder einzurichten - die Antwort käme dann von dem verwendeten DoT-Server, d.h. dieser DoT-Server filtert unbounds DNS-Anfragen und blockiert letztendlich die in Pi-hole korrekt erlaubte Domäne.
Du solltest also entweder auf einen anderen, nicht filternden DoT-Server wechseln, oder aber unbound wieder -wie von Pi-holes Guide vorgeschlagen- als rekursiven Resolver nutzen.
Ja, das mit den DoT Servern wollte ich mal versuchen und habe welche in der FritzBox eingetragen aber auch in der unbound Konfig ganz unten und aus irgendeinem Grund, wo ich mich nicht gerade dran erinnern kann wieder gelöscht bzw. in der FritzBox deaktiviert aber in der unbound Konfiguration nichts verändert, könnte es daran liegen? Sollte ich die letzten Zeilen mit den 3 Upstream Servern und den Eintrag forward tls upstream löschen oder muss ich da noch etwas beachten?
Ich habe die Unbound Konfiguration gestern Abend noch auf den Standard gesetzt und die gewünschten Domains als Wildcard nochmal auf die Whitelist gesetzt und seitdem keine Aussetzer mehr feststellen können. Das Problem, wenn ich mich auf die Admin Oberfläche über pi.hole/admin/ einlogge, besteht allerdings immer noch. Ich rufe die Seite ganz normal auf, gebe das Passwort ein, dann kommt die Fehlermeldung Safari kann die Seite nicht öffnen, da die Netzwerkverbindung unterbrochen wurde, obwohl das WLAN nie weg war. Dann drücke ich auf Reload gebe mein Passwort erneut ein und dann geht es plötzlich. Könntest du da auch nochmals behilflich sein? Schönen Abend!
).
