Habe seit Jahren einen PiHole 4.0 mit RP3B im Einsatz und der macht was er soll. Eingerichtet habe ich ihn nach Anleitungen im Internet und verfüge leider nicht über tieferes Wissen. Ich habe den DNS-Server in die Netzwerkkonfigurationen der Devices eingetragen. Im Netzwerk ist der Raspberry mit Kabel verbunden.
Um einem evtl. Ausfall zuvor zu kommen, habe ich einen neuen RP3B gekauft und diesmal mit DietPi, PiHole 5 und Unbound bespielt. Die Werbung wird viel besser geblocked, jedoch habe ich beim Seitenaufruf von z.B. N-TV.de eine Wartezeit von ca. 5 sec. Bei erneutem Aufruf nicht, nach einiger Zeit jedoch wieder.
Dann habe ich mir einen RP4 gekauft und nur mit PiOS und PiHole 5 bespielt - genau das Gleiche: Funktion da, aber mit Zeitverzögerung von 5 sec.
Ich vermute einen Konfigurationsfehler bei den Raspberries, habe aber keine Idee wo ich suchen soll. Zuerst habe ich die Frage im RaspberryPi Forum gestellt - leider bisher ohne Lösung. Ich kann Ausgaben von DNScheck.tools oder von IP a einstellen.
Poste mal den Link zum Debug File hier für den Support.
PiHole läuft schon sehr flott und ohne Verzögerung auf einem Pi2B mit aktuellem RaspiOS und Unbound. N-TV.de ist im Augenblick auf dem Schirm. Mit einem Pi3 oder Pi4 ist es schon überqualifiziert, sofern nicht noch andere Dinge auf dem Pi laufen.
Ich hatte nur kurz Zeit einen Blick rein zu werfen, aber in Deinem Debug Log fällt mir auf, dass Dein Router sich selbst als DNS Server an die einzelnen Geräte aussteuert. Aber gut, das meinst Du, hast Du kompensiert
Ist das Pi-hole als einziger DNS-Server dort eingetragen? Eine Fehlerquelle könnte z.B. sein dass der ein weiterer DNS-Server "sekundär" eingetragen ist. Bitte beachte, dass es gibt keine Rangfolge im DNS-System, es werden alle gefragt. Die Wortwahl "primär"/"sekundär" ist ziemlich unglücklich und findet sich z.B. bei Windows Betriebssystemen. Andere Systeme wir Linux sind da "ehrlicher" indem sie Dir erlauben beliebig viele Server anzugeben, aber diese auch gleichberechtigt nebeneinander zu stellen um klar zu machen, dass es eine solche Abstufung nicht gibt.
Hier könnten Anfragen, die zunächst an "den falschen" gestellt werden perfekt zu der von Dir beobachteten Symptomatik passen.
Hallo zusammen,
Vielen Dank für das Feedback.
Es ist tatsächlich so, dass der Router eine Standarddefinition zum DNS-Server hat. Der Router ist von Vodafone und da ist nichts verändert. Der Router hat sowohl eine IPv4 DNS Adresse, als auch eine IPv6 DNS Adresse.
Bei meinen Netzwerk-Devices habe ich überall nur die IPv4 Adresse des PiHole eingetragen - keine weitere Alternative.
Ich habe aktuell 3 Raspberries mit PiHole im Netzwerk:
Die Nr. 225 ist mehrere Jahre alt, funktioniert ohne Verzögerung und hat PiHole 4.0. Mit „funktioniert“ meine ich, dass wenn ich die Adresse in ein Device als DNSServer eintrage, gibt es beim Surfen keinen Verzug. Diesen Raspberry wollte ich in „Rente“ schicken.
Die Nr. 230 hat als Betriebssystem dietpi, es läuft phihole 5.0 und unbound.
Die Nr. 234 hat PiOs und nur PiHole 5.0.
Diese beiden Raspberries weisen, wenn sie als DNSServer verwendet werden, eine Verzögerung von ca. 5 sec auf. Meist nur beim ersten Aufruf einer Internetadresse mit dem Browser, kurz danach geht es ohne Verzug und nach einiger Zeit ist die Verzögerung wieder da.
Ich habe eigentlich falsche Einstellungen des Raspberry im Verdacht, oder evtl. IPv6 Adressen, die ich bei den Netzwerk-Devices oder im Router nicht auf den PiHole eingestellt habe.
Leider kenne ich mich nicht so richtig aus und habe mich bemüht im IPv4 Bereich zu bleiben.
Es ist prinzipiell einfach herauszufinden, wieso Queries lange brauchen bzw. zumindest herauszufinden in welchem Schritt. Von dort ist es bis zur Lösung nicht weit.
Bitte zunächst
DEBUG_QUERIES=true
in die Datei /etc/pihole/pihole-FTL.conf (bitte neu erstellen falls noch nicht vorhanden) und dann
pihole restartdns
Anschließend kommt der trickreiche Teil: Herausfinden welche Domain langsam ist. Dafür im Web "herumsurfen" bis es eben auffällt, idealerweise von einem Gerät im Netzwerk wo das Problem bekannt ist ein dig www.tagesschau.de o.Ä. abfeuern.
Dann mittels folgender Datenbankabfrage ermitteln welche Anfragen > 1 Sekunde gedauert haben:
pihole-FTL sqlite3 -h /etc/pihole/pihole-FTL.db "SELECT * FROM queries WHERE reply_time > 1 ORDER BY id DESC LIMIT 5"
hier unter der Rubrik domain schauen. Wenn wir nun wissen welche Domain verantwortlich ist, dann bitte die passenden Zeilen aus der Datei /var/log/pihole/pihole.log sowie /var/log/pihole/FTL.log heraus suchen.
Ich weiß, das sieht erstmal nach recht viel Arbeit aus, aber es sollte nicht mehr Arbeit sein als es für mich war das hier für Dich zu formulieren Mit den Daten sollten wir auf jeden Fall dem Problem auf die Spur kommen können.
Ich bin häufig auf n-tv.de und da ist es mir aufgefallen.
Mit welchem Befehl zeige ich die logs an, wenn ich mit ssh zugreife? Mit sudo nano und dann den link mit Dateinamen?
Wir wissen aber noch nicht, ob es auch an n-tv.de liegt oder evtl. an einer Komponente, die diese Seite von einem der zahlreichen dort verwendeten externen Anbieter bezieht, ohne die die Darstellung der Webseite (noch) nicht möglich ist.
Besser less, z.B.
less /var/log/pihole/pihole.log
dort mit Pfeiltasten navigieren, bzw. mit / und dann Text eingeben suchen.
bei less /var/log/pihole/pihole.log
bekomme ich: /var/log/pihole/pihole.log: Permission denied
Ich habe dann mit sudo nano die 2 Dateien geöffnet und mit ^Q nach n-tv.de gesucht.
Beim Raspberry Nr. 234 (PiOS) kam diese Antwort:
Datei /var/log/pihole/pihole.log
gelöscht
das war alles - kein n-tv.de da drin.
Dann habe ich mich auf den 2.Raspberry, die Nr. 230 mit dietpi, Pihole und unbound aufgeschaltet. Der hat keinen Inhalt von /var/log/pihole/pihole.log
Datei: /var/log/pihole/FTL.log
So, das sagt uns zumindest, dass es nicht an n-tv.org liegt. Sämtliche Anfragen waren innerhalb der selben Sekunde beantwortet (Jul 10 19:16:31). Zwei Sekunden später hat Dein Pi-hole eine andere Anfrage erhalten, diese aber auch sofort beantwortet (Jul 10 19:16:33).
Dann ist der Debug Modus nicht nach meiner obigen Anleitung aktiviert. Das Log wird dann sehr rege sehr voll geschrieben werden.
Hmm, kommt drauf an wie Du Pi-hole hier installiert hast. Wenn logging deaktiviert ist, dann bleibt die Datei leer. Wenn Du den Debug Modus von FTL einschaltest, wird zumindest die FTL.log Datei befüllt.
Das könnte in Richtung des Problems deuten - könnte aber auch völlig unabhängig sein. Was hier passiert ist, ist, dass eine Antwort aufgrund von Größenbeschränkungen des UDP-Datenprotokolls abgeschnitten wurde und nicht validiert werden kann. Der anfragende Rechner wird in diesem Fall darüber informiert, dass er die gleiche Anfrage über das TCP-Protokoll wiederholen soll wo dieses Problem nicht auftritt. Normalerweise funktioniert das reibungslos und ist hier vermutlich keine große weitere Rede wert, aber ich dachte ich erwähne es trotzdem.
Also: Wir haben noch nicht herausgefunden was langsam läuft, mein Vorschlag wäre:
Debug Modus wie oben beschrieben (DEBUG_QUERIES=true in pihole-FTL.conf) aktivieren
Herausfinden ob es eine bestimmte Domain gibt, die lange dauert über den von mir oben vorgeschlagenen sqlite3 Befehl
Falls das alles nichts bringt, dann versuch mal mit nur einem Deiner Geräte das Pi-hole zu nutzen. Sobald das Problem dann sichtbar wird, können wir uns gerne die gesamte pihole.log Datei zusammen anschauen, da müsste sich dann ja erkennen lassen was langsam war.
ich habe mich auf meine 2 Raspberries mit ssh angemeldet und die /etc/pihole/pihole-FTL.conf Dateien um die DEBUG_QUERIES=true Einträge erweitert.
Dann habe ich pihole restartdns gemacht.
Bei meinem iPad habe ich den DNS-Server eingestellt, mich im Wlan ab und wieder angemeldet und dann n-tv.de aufgerufen. Es hat einige Sekunden gedauert.
Den Vorgang habe ich 2 x gemacht, einmal für den DNS-Server Nr. 234 und einmal für 230. Beides Mal exakt das gleiche Verhalten.
Die Datenbankabfrage hat mich überrascht.
Bei der Nr. 230 war unter client mein iPad nicht mit aufgeführt,
bei der Nr. 234 schon, aber nur mit Abfragen die 4 und 11 Tage zurück lagen (timestamp).
Ich bewerte das so, dass ich bei n-tv.de als Anwender wohl warten muss, der Pihole aber seinen Dienst wie gewünscht erledigt.
Im Log: /var/log/pihole/FTL.log stehen IPv4 und IPv6-Adressen und Ports, wo ich das Risiko nicht abschätzen kann, ob die Veröffentlichung für mich Nachteile haben kann. Ich habe daraufhin auch meine alten Logs aus den älteren Beiträgen gelöscht.
Vielleicht liegt mein Problem nicht am Pihole, sondern an falschen Einstellungen oder am Raspberry selbst - keine Ahnung. Werde weiter experimentieren.
Ja, ich sehe das auch so, aber es sagt uns jetzt zunächst nur, das keine einzelne erforderliche Abfrage jeweils mehr als eine Sekunde gedauert hat. Es kann immer noch sein, dass eine Anfrage 0.8 Sekunden dauert, dann kam eine weitere mit 0.7 Sekunden dazu, etc....
Dafür wäre es relevant das ganze Log studieren zu können. Du kannst Dateien mit dem Entwicklerteam privat teilen wenn Du Sie über die Tricorder-Funktion hochlädst, z.B.
und dann öffentlich den Link mit uns teilst. Auch Du selbst wirst Ihn mangels Berechtigungen nicht lesen können, wir brauchen den Link aber um auf die Daten zuzugreifen.
Darauf basieren können wir weiter an dem Mysterium forschen - aber wie immer ist alles natürlic völlig freiwillig und nur ein Angebot unsererseits
Habe mich mit ssh am DNS-Server 234 angemeldet.
Um 9:58h pihole restartdns durchgeführt.
Mit meinem iPhone (Nr.218) N-TV.de aufgerufen - ging schnell.
Mit meinem iPad (Nr.215) N-TV.de aufgerufen - ging langsam.
cat /var/log/pihole/pihole.log | pihole tricorder hat diese Antwort gegeben:
geprüft, ob Datei vorhanden mit:
sudo nano /var/log/pihole/pihole.log
Datei ist da.
Dann mit ssh am DNS-Server 230 angemeldet.
pihole restartdns ca. 10:16h - Achtung Uhrzeit 1 h zurück = Winterzeit.
Mit meinem iPhone (Nr.218) N-TV.de aufgerufen - ging schnell.
Mit meinem iPad (Nr.215) N-TV.de aufgerufen - ging leider auch schnell.
cat /var/log/pihole/pihole.log | pihole tricorder
Upload successful, your token is: https://tricorder.pi-hole.net/Nf1Ti52I/
cat /var/log/pihole/FTL.log | pihole tricorder
Upload successful, your token is: https://tricorder.pi-hole.net/knocrASf/
Mit den Daten sollten wir auf jeden Fall dem Problem auf die Spur kommen können.