Web interface wird im laufe der Zeit immer langsamer

Hallo,

Pi-hole läuft schon seit einiger Zeit sehr stabil. Nur habe ich im laufe der Zeit immer wieder das Problem dass das Web Interface immer langsamer wird bis ich mit "Pihole restartdns" das Subsystem wieder neu starte. Danach läuft es wieder für ein paar Wochen.

Was dabei auffällt sind die Localhost queries die alle Stunde auftreten, nach einem Neustart sind das ca. 50 jede Stunde, das schaukelt sich über die Tage immer weiter nach oben bis es ca. 400 sind. Mit steigender Anzahl der queries wird dann das Web-Interface immer langsamer.

Hier noch das Debug-Token:
https://tricorder.pi-hole.net/mgb4xjpm3z

Die Anzal der DNS-Anfragen hat tatsächlich und erwartbar einen Einfluss auf die für den Aufbau des Dashboards benötigte Zeit .

Ungewöhnlich ist in Deinem Fall die Zunahme der von Pi-hole einmal stündlich durchgeführten Rückwärtsauflösungen.

Welche Adressen versucht Pi-hole dabei aufzulösen?

grep -n "\[PTR\]" /var/log/pihole.log

Hier ein Ausschnitt, es gibt sehr viele Log Einträge. Wenn Du das Log komplett brauchst kann ich die Datei gerne zum Download bereitstellen.

1309:Nov 4 02:00:00 dnsmasq[1698]: query **[PTR]** 11.0.168.192.in-addr.arpa from 127.0.0.1
1311:Nov 4 02:00:00 dnsmasq[1698]: query **[PTR]** 11.0.168.192.in-addr.arpa from 127.0.0.1
1313:Nov 4 02:00:00 dnsmasq[1698]: query **[PTR]** 3.3.f.1.b.5.b.6.e.2.c.0.2.4.8.e.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1316:Nov 4 02:00:03 dnsmasq[1698]: query **[PTR]** 3.3.f.1.b.5.b.6.e.2.c.0.2.4.8.e.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1318:Nov 4 02:00:03 dnsmasq[1698]: query **[PTR]** 1.4.7.1.2.a.3.7.3.8.3.e.7.d.d.1.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1321:Nov 4 02:00:04 dnsmasq[1698]: query **[PTR]** 1.4.7.1.2.a.3.7.3.8.3.e.7.d.d.1.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1323:Nov 4 02:00:04 dnsmasq[1698]: query **[PTR]** 0.9.9.3.8.4.7.f.8.0.5.1.a.6.5.c.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1326:Nov 4 02:00:07 dnsmasq[1698]: query **[PTR]** 0.9.9.3.8.4.7.f.8.0.5.1.a.6.5.c.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1328:Nov 4 02:00:07 dnsmasq[1698]: query **[PTR]** 20.0.168.192.in-addr.arpa from 127.0.0.1
1330:Nov 4 02:00:07 dnsmasq[1698]: query **[PTR]** 22.0.168.192.in-addr.arpa from 127.0.0.1
1332:Nov 4 02:00:07 dnsmasq[1698]: query **[PTR]** 4.0.5.6.8.f.6.0.e.0.b.b.3.6.d.e.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1335:Nov 4 02:00:07 dnsmasq[1698]: query **[PTR]** 4.0.5.6.8.f.6.0.e.0.b.b.3.6.d.e.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1337:Nov 4 02:00:07 dnsmasq[1698]: query **[PTR]** 7.3.1.e.0.0.3.b.5.9.f.9.1.6.d.4.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1340:Nov 4 02:00:11 dnsmasq[1698]: query **[PTR]** 7.3.1.e.0.0.3.b.5.9.f.9.1.6.d.4.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1342:Nov 4 02:00:11 dnsmasq[1698]: query **[PTR]** 6.a.b.b.c.a.b.a.f.3.3.a.5.6.4.0.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1345:Nov 4 02:00:11 dnsmasq[1698]: query **[PTR]** 6.a.b.b.c.a.b.a.f.3.3.a.5.6.4.0.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1347:Nov 4 02:00:11 dnsmasq[1698]: query **[PTR]** b.4.a.6.c.b.8.8.0.6.2.0.4.a.9.b.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1350:Nov 4 02:00:12 dnsmasq[1698]: query **[PTR]** b.4.a.6.c.b.8.8.0.6.2.0.4.a.9.b.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1352:Nov 4 02:00:12 dnsmasq[1698]: query **[PTR]** d.3.9.b.c.6.1.a.a.a.0.6.1.1.c.0.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1355:Nov 4 02:00:12 dnsmasq[1698]: query **[PTR]** d.3.9.b.c.6.1.a.a.a.0.6.1.1.c.0.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1357:Nov 4 02:00:12 dnsmasq[1698]: query **[PTR]** 113.0.168.192.in-addr.arpa from 127.0.0.1
1359:Nov 4 02:00:12 dnsmasq[1698]: query **[PTR]** 1.b.c.3.2.6.9.b.7.e.a.4.0.0.8.f.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1362:Nov 4 02:00:13 dnsmasq[1698]: query **[PTR]** 1.b.c.3.2.6.9.b.7.e.a.4.0.0.8.f.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1364:Nov 4 02:00:13 dnsmasq[1698]: query **[PTR]** 6.5.f.b.a.1.2.c.c.a.8.8.f.5.d.1.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1367:Nov 4 02:00:14 dnsmasq[1698]: query **[PTR]** 6.5.f.b.a.1.2.c.c.a.8.8.f.5.d.1.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1369:Nov 4 02:00:14 dnsmasq[1698]: query **[PTR]** 3.9.6.4.1.7.4.5.d.9.e.7.2.d.5.5.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1372:Nov 4 02:00:14 dnsmasq[1698]: query **[PTR]** 3.9.6.4.1.7.4.5.d.9.e.7.2.d.5.5.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1374:Nov 4 02:00:14 dnsmasq[1698]: query **[PTR]** 7.d.6.9.b.9.e.5.d.3.9.5.4.0.c.7.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1377:Nov 4 02:00:15 dnsmasq[1698]: query **[PTR]** 7.d.6.9.b.9.e.5.d.3.9.5.4.0.c.7.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1379:Nov 4 02:00:15 dnsmasq[1698]: query **[PTR]** c.9.e.5.e.5.0.c.c.9.b.8.3.2.5.b.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1382:Nov 4 02:00:15 dnsmasq[1698]: query **[PTR]** c.9.e.5.e.5.0.c.c.9.b.8.3.2.5.b.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1384:Nov 4 02:00:15 dnsmasq[1698]: query **[PTR]** 4.3.f.7.2.6.d.4.4.5.b.d.f.b.8.6.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1387:Nov 4 02:00:16 dnsmasq[1698]: query **[PTR]** 4.3.f.7.2.6.d.4.4.5.b.d.f.b.8.6.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1389:Nov 4 02:00:16 dnsmasq[1698]: query **[PTR]** b.7.d.d.9.3.e.8.4.a.0.a.b.f.d.2.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1392:Nov 4 02:00:16 dnsmasq[1698]: query **[PTR]** b.7.d.d.9.3.e.8.4.a.0.a.b.f.d.2.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1394:Nov 4 02:00:16 dnsmasq[1698]: query **[PTR]** f.1.e.3.f.2.0.4.e.8.3.7.b.5.5.e.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1397:Nov 4 02:00:17 dnsmasq[1698]: query **[PTR]** f.1.e.3.f.2.0.4.e.8.3.7.b.5.5.e.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1399:Nov 4 02:00:17 dnsmasq[1698]: query **[PTR]** f.d.d.5.8.d.b.4.4.e.6.9.c.1.9.6.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1402:Nov 4 02:00:17 dnsmasq[1698]: query **[PTR]** f.d.d.5.8.d.b.4.4.e.6.9.c.1.9.6.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1404:Nov 4 02:00:17 dnsmasq[1698]: query **[PTR]** d.3.0.4.2.5.e.7.c.6.b.d.f.a.4.2.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1407:Nov 4 02:00:17 dnsmasq[1698]: query **[PTR]** d.3.0.4.2.5.e.7.c.6.b.d.f.a.4.2.8.9.7.3.0.4.b.0.d.0.1.8.2.0.a.2.ip6.arpa from 127.0.0.1
1409:Nov 4 02:00:17 dnsmasq[1698]: query **[PTR]** 171.0.168.192.in-addr.arpa from 127.0.0.1

Das sieht erst einmal nach regulären Anfragen aus, sofern 2a02:810d:0b40:3798 Dein aktuelles IPv6-Präfix ist.

Könntest Du bitte ein neues Debug Token posten oder oben ersetzen?
Dein letztes ist bereits abgelaufen.

Wieviele Geräte sind in Deinem Netzwerk unterwegs?

Ja, das ist mein aktuelles Präfix

Gerne, hier das neue Token:
https://tricorder.pi-hole.net/zkc85fjpa9

Das ist ein kleines Netzwerk:
2 Laptops
2 Mobiltelefone
1 NAS
1 PC
1 Tablet

Internetzugang läuft über Vodafone Kabel (Fritzbox 6490) - Echter Dualstack mit IPv4 und IPv6

Mit IPv6 wäre normalerweise bei 7 Geräten mit 14 bis 21 Client-IPs in Pi-holes Query Log zu rechnen (je eine IPv4 und ein bis zwei IPv6).

Die zunehmend höhere Zahl an Rückwärtsanfragen könnte in Deinem Fall mit IPv6 *Privacy Extensions* (PE) zusammenhängen (klicken für Details):

Du verteilst aktuell die öffentliche IPv6-Adresse Deines Pi-hole-RPis als DNS-Server.

Damit werden Deine Clients Pi-hole ihrerseits über ihre öffentliche IPv6-Adressen anfragen.
Für öffentliche IPv6-Adressen ist die Verwendung von IPv6 Privacy Extensions sinnvoll, damit Du nicht die MAC-Adresse Deiner Geräte verrätst und außerdem ein Tracking erschwert wird.

Zu diesem Zweck wechselt die öffentliche IPv6-Adresse nach einer bestimmten Zeit, i.d.R nach 24 Stunden, je nach OS aber auch kürzer (ich erinnere mich an zwei Stunden bei Ubuntu).
Die älteren IPv6-Adressen bleiben dabei aber noch eine Zeit lang weiter für eingehende Anfragen gültig, so dass zu einem Zeitpunkt durchaus mehrere öffentliche IPv6-Adressen auf einem Netzwerk-Interface zugeordnet sein können.


Generell läufst Du bei Verwendung der öffentlichen IPv6-Adresse (aus dem Bereich 2000::/3) für Pi-hole in das Risiko, dass sich sowohl IPv6-Präfix (bei Neuzuteilung durch den ISP) als auch Interface Identifier (z.B. eben durch PE) ändern können.
Pi-hole muss aber für Clients unter einer festen IP-Adresse erreichbar sein, sonst kommt es zu Fehlern wie in Deinem Log:

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve r9---sn--5uaeznyz.googlevideo.com via localhost (::1)
[✗] Failed to resolve r9---sn--5uaeznyz.googlevideo.com via Pi-hole (2a02:<redacted>:d8bf)
[✓] doubleclick.com is 2a00:1450:4016:802::200e via a remote, public DNS server (2001:4860:4860::8888)

Um das zu vermeiden, kannst Du stattdessen eine ULA-Adresse verwenden, sofern Dein Router dies zulässt (Bereich fd00::/8).
Aktuell ist eine solche Adresse bei Dir laut Debug Log nicht aktiv.

PE sind allerdings wahrscheinlich auch für solche ULA-Adressen aktiv.

Sofern Deine Netzwerkgeräte alle im selben Netzwerksegment unterwegs sind (vereinfacht: direkt mit dem Router verbunden), kannst Du stattdessen auch die link-lokale IPv6 Deines RPi verwenden (Bereich fe80::/10).

Wahlweise bestünde eventuell auf einem Client die Möglichkeit, die IPv6 prefix policies jeweils so anzupassen, dass bei Verfügbarkeit von IPv4-Adressen auch bevorzugt IPv4 statt IPv6 genutzt wird. Für Smartphones und Tablets geht das gewöhnlich nicht.

Und schliesslich:
Da Pi-hole über die öffentliche IPv6-Adresse theoretisch auch öffentlich erreichbar ist, sofern Dein Router dies nicht unterbindet oder Du irrtümlich den DNS-Port im Router freigegeben hast, solltest Du auch überprüfen, dass die zunehmenden Anfragen nicht auf externe Clients ausserhalb Deines Netzwerks zurückzuführen sind.

Dies sollte aus Pi-hole's Netzwerkübersicht erkennbar sein, die Du über Tools | Network erreichst.
Dort sollten prinzipiell keine unbekannten Einträge, speziell keine öffentlichen IPv6-Adressen mit einem anderen als Deinem Präfix auftauchen.

Danke für die ausführliche Antwort, ich habe jetzt einmal die link-lokale IPv6 angegeben und nochmal das Subsystem neu gestartet. Mal sehen ob sich das Verhalten jetzt ändert.

Die Netzwerkübersicht zeigt keine unbekannten Einträge, allerdings ist mir beim durchgehen der Einstellungen auf dem Router aufgefallen dass der DHCP Server für IPv6 noch auf dem Router aktiv war.

Ich schaue mir das Verhalten die nächsten Tage an und gebe dann noch Rückmeldung.

Ich habe das Verhalten jetzt drei Tage beobachtet und die Localhost queries sind seit dem letzten Neustart konstant, immer ca. 38 jede Stunde. Passt also alles, vielen Dank für die schnelle Hilfe

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.