ich hatte eine "Eingebung" und es nochmal probiert mit:
sudo cat /var/log/pihole/pihole.log | pihole tricorder
Upload successful, your token is: https://tricorder.pi-hole.net/fVnGiNsD/
Tut mir leid, ich war unterwegs und hatte keine Zeit mich hier zwischendurch damit zu befassen ... leider ist Dein Upload zwischenzeitlich aus Datenschutzgründen automatisch gelöscht worden und Du müsstest das Experiment leider wiederholen... 
Kein Thema, mittlerweile kenne ich die Raspberry-Befehle und wer Hilfe will, muss was tun...
Ok, ich habe alles wiederholt, aber n-tv.de ist jeweils ohne Verzögerung aufgerufen worden. Ich habe also dokumentiert, dass ich keine Probleme habe !!??!!??
Ablauf: ich habe 2 neue PiHoles (Nr.234 und 230) und n-tv.de mit 2 Devices (Nr. 218 und 215) aufgerufen.
Server 234
pihole restartdns 11:22h
Zugriff mit iPhone 218 auf n-tv.de (schnell)
Zugriff mit iPad 215 auf auf n-tv.de (schnell)
Upload successful, your token is: https://tricorder.pi-hole.net/d721SC1C/
Upload successful, your token is: https://tricorder.pi-hole.net/Gtg51aVp/
Server 230
pihole restartdns ca. 11:33h - Uhrzeit 1 h zurück
Zugriff mit iPhone 218 auf auf n-tv.de (schnell)
Zugriff mit iPad 215 auf auf n-tv.de (schnell)
Upload successful, your token is: https://tricorder.pi-hole.net/7it4SoRn/
Upload successful, your token is: https://tricorder.pi-hole.net/mJGWqOGQ/
Der Verweis auf die Uhrzeit soll dazu dienen, die Stelle im LOG schneller zu finden.
... wenn überhaupt was zu finden ist, weil heute waren ausnahmsweise die Aufrufe alle zufriedenstellend.
Ohne Probleme haben wir leider auch nichts was ich mir anschauen könnte. Wir suchen ja nach auffällig langsamen Abfragen. Um diese zu identifizieren müssen sie natürlich... naja... langsam... sein.
Hallo,
heute beim Surfen ist die Verzögerung ein paar mal aufgetreten. Um 2:20h, 9:20h, 12:04h und 16:09h.
Hier die pihole.log:
Upload successful, your token is: https://tricorder.pi-hole.net/oUN9vOht/
Der Upload hat lange gedauert.
Der Upload der FTL.log hat noch viel länger gedauert und ist 2 x abgebrochen:
[✗] uploading failed, contact Pi-hole support for assistance.
[i] Error message: curl: (22) The requested URL returned error: 502
erst der dritte Versuch hat funktioniert:
Upload successful, your token is: https://tricorder.pi-hole.net/qD3nx5Mf/
Das FTL log ist wesentlich größer und der Upload eigentlich kaum für solch große Dateien (19 MB in diesem Fall) gedacht.
Schauen wir uns zunächst Jul 22 02:20:50 an: Alle Anfragen werden innerhalb von längstens 50 ms beantwortet. Insgesamt wurden im Zeitraum 02:20:50 - 02:20:54 136 Queries von Deinem Client an das Pi-hole abgesetzt (36x A, 48x AAAA, 52x HTTPS), die jeweils innerhalb von durchschnittlich 26 ms beantwortet wurden. Davon gehen durchschnittlich 23 ms auf die Kommunikation mit dem Upstream DNS Server (OpenDNS) drauf, etwa 2 - 4 ms entfallen auf Verarbeitung innerhalb Deines Pi-hole.
Das Problem ist hier eindeutig, dass die Anfragen alle nacheinander eintrudeln. Der erste Schwung ist um 02:20:50.368 vollständig beantwortet worden, die nächsten Anfragen werden dann erst eine ganze Zeit später um 02:20:50.554 gestellt, also immerhin mit 0.2 Sekunden Verzögerung. Ich nehme also an, dass der Client die Ergebnisse aus der ersten Runde hernimmt, dann entsprechende Skripte, o.Ä. herunterlädt um dann wiederum neue Requests absetzt. Die nächste Pause tritt dann von 02:20:50.779 - 02:20:50.926 auf.
Um ehrlich zu sein, sehe ich da angesichts des extrem seriellen Verhaltens des Clients eigentlich recht wenig was man optimieren kann. Pi-hole v6.0 hat einen "Cache Optimizer", der nach einer gewissen Trainingsphase "erlernt" haben sollte, dass Du die n-tv Seiten ab und zu öffnest und das Wissen um deren Adressen entsprechend vorrätig haben wird. Ob das das Problem aber hinreichend abmildert mag ich gerade nicht zu ermessen, es würde definitiv aber die jeweils 20 ms lange Anfrage/Antwort Zeit zu OpenDNS wegfallen.
Die anderen Zeiten habe ich nicht studiert, da das doch etwas zeitaufwendig ist und ich annehme, dass es sich überall gleich verhält.
Hallo DL6ER,
Das heißt für mich vermutlich, dass ich damit leben muss…
Ich verstehe nicht, dass der Effekt mal auftritt und mal nicht.
Bei meinen 2 neuen DNS Servern ist gemeinsam, dass es PiHole 5 ist.
Bei einem ist unbound dabei, beim anderen nicht. Einer ist ein Raspberry 4 der andere ein 3er.
Gibt es vielleicht eine Einstellung an den Settings, wo ich was falsch gemacht haben könnte?
Wie auch immer, vielen Dank für die Energie, die Du für die Analyse aufgewendet hast.
Ich denke nicht. Wenn Du willst, könntest Du die Pi-hole v6.0 Beta ausprobieren:
Hier gibt es den sog. "Cache-Optimizer", der die Anfrage-/Antwortzeit ab dem zweiten Mal deutlich reduzieren kann. Evtl. reicht das für einen spürbaren Unterschied. Ansonsten würde ich das Problem eher auf seitens des Clients sehen, denn normalerweise sollte auch dort der Cache dafür sorgen, dass nicht immer alles komplett neu geholt werden muss. Hast Du ggfs. eine Option im Browser aktiviert, die den Cache/Verlauf/etc. beim Beenden oder anderswie periodisch leert/löscht?
Hallo DL6ER,
ich bin nicht so richtig fit mit Raspberries und PiOS. Auch mit Docker kenne ich mich nicht aus. Wenn das erste Update auf 6.0 über die Webanwendung von PiHole verfügbar ist, werde ich das ausprobieren.
Ich setze auf dem iPhone und iPad nur Safari ein. Bei den Standardeinstellungen habe ich nichts gefunden, was den Cache regelmäßig löscht. Da gibt es irgendwelche mystischen Schalter unter „Erweitert“ und „Feature Flags“, aber da habe ich bisher die Finger von gelassen.
Ich verwende Safari ausschließlich im „Private Modus“, was die Surf-Historie aus dem Cache löschen soll. Ob das auch den DNS Cache löscht, weiß ich nicht.
Das dürfte dann die Erklärung sein. Ich habe keine Apple Geräte mit denen ich das selbst verifizieren könnte, kann mir aber gut vorstellen, dass es genau daran liegt. Mit Pi-hole v6.0 dürfte die Symptomatik zumindest etwas abgemildert werden. Am Ende liegt es aber an einem schlechten Design der Website von n-tv und Deiner Wahl, dass Dein Browser ständig alles wieder vergisst was er zuvor schon einmal gesehen hat 
Updates werden nicht über die Weboberfläche durchgeführt, dort erscheint nur ein Hinweis. Das hat Sicherheitsgründe, die wir sehr ernst nehmen - der DNS Server ist zentrales Element in Deinem Netzwerk und sollte potentiellen Angreifern so wenig Angriffsfläche wie möglich bieten.
Dass es mit einem Pi-hole ohne Verzögerungen funktioniert, und mit einem anderen aber 5 Sekunden dauert, würde ein rein clientseitiges Problem eher unwahrscheinlich machen.
unbound könnte hier einen Einfluss haben, da die erstmalige rekursive Auflösung tatsächlich etwas mehr Zeit beansprucht.
Allerdings sollten sich nennenswerte initiale Verzögerungen dann auch in Pi-holes Datenbank und Logs wiederfinden, und das war bei Dir ja nicht der Fall.
Zudem kann ich auf meinem System keine fünfsekündige Verzögerung beim Aufruf von ntv feststellen, auch bei Verwendung von unbound als Pi-holes Upstream.
(Datenbank-Abfrage)
pihole-FTL sqlite3 -h /etc/pihole/pihole-FTL.db "SELECT domain, reply_time, datetime(timestamp, 'unixepoch') as date FROM queries WHERE domain LIKE '%ntv.de' ORDER BY 2 DESC LIMIT 20;"
domain reply_time date
---------- ---------- -------------------
www.ntv.de 0.2192 2024-07-26 08:23:19
www.ntv.de 0.201 2024-07-26 08:23:19
ntv.de 0.0229 2024-07-26 08:23:19
www.ntv.de 0.0209 2024-07-26 09:13:28
www.ntv.de 0.0028 2024-07-26 08:23:19
Zusammengenommen würde das wiederum nahelegen, dass es auch nicht an Pi-hole und unbound liegen kann.
IPv6-fähige Clients würden bevorzugt zunächst eine Auflösung über IPv6 versuchen.
Hast Du im Router ggf. eine IPv6-Adresse Deines alten Pi-hole 4 eingetragen, so dass Deine IPv6-Clients diese verwenden könnten?
Ist diese noch gültig bzw. ist Dein alter Pi-hole 4 noch im Netz?
Wenn über die ggf. konfigurierte IPv6-Adresse kein DNS-Server erreichbar ist, würde ein IPv6-Client zunächst erfolglos über IPv6 anfragen und erst nach einem Time-out eine Auflösung über die IPv4-Adresse des Pi-holes anfordern.
Das könnte möglicherweise Deine Beobachtung erklären.
1 Like
Der alte PiHole 4.0 ist immer noch im Netz. Ich habe keinen PiHole über den Router als DNS Server eingebunden, sondern immer nur über die einzelnen Devices.
Außerdem habe ich mich bemüht, IPv6 nicht zu verwenden, statische IPv4 Adressen einzusetzen und wenn ich dran gedacht habe, oder es möglich war, IPv6 abzuschalten.
Bei meinem iPad habe ich nicht probiert, IPv6 Adressen zu löschen - keine Ahnung, ob sowas überhaupt geht.
Am iPad ist unter DNS-Server in den Wlaneinstellungen nur die statische IPv4 des PiHole eingestellt.
Den Hinweis auf den „privaten Surfmodus“ bei Safari probiere ich gerade aus. Ich habe den aktuell nicht aktiviert und bisher keine Verzögerung gehabt.
- die Testphase ist aber ja noch nicht lang am laufen
- beim alten PiHole 4.0 ist mir früher keine Verögerung bei aktiviertem „privaten Surfmodus“ aufgefallen.
Kleines Feedback: seit ich vor ca. 1 Woche den „privaten Surfmodus“ ausgeschaltet habe, sind die Verzögerungen nicht wieder aufgetreten.
Vielen Dank an Alle für die Unterstützung.
1 Like
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.