Pihole überlastet? Plötzlich viele Anfragen und Internetseiten werden nicht mehr geöffnet

JayDee · January 30, 2025, 1:43pm

Hallo Forum,

ich habe unregelmäßig das Phänomen,dass mein pihole (RP5) scheinbar plötzlich so viele Anfragen bekommt das er diese nicht mehr verarbeiten kann bzw. dann Internet Seiten nicht mehr geöffnet werden.
Ein "Restart DNS Resolver" oder "Restart systems" in den pihole Interface Settings löst das Problem nicht. Erst wenn ich in meiner Fritzbox auf den automatischen DNS im Reiter Internet/Zugangsdaten/DNS-Server wechsle und in den IPv4 Einstellungen bei DNS die Fritzbox eingeben, geht es relativ schnell wieder.

Im folgenden Screenshot kann man erkennen, dass um 14 Uhr die Anfragen plötzlich sprunghaft ansteigen. Der Load und die Memory Usage war aber unauffällig.

Hat jemand ein ähnliches Problem bzw, könnt ihr mir sagen was ich alles machen und prüfen kann um das Problem zu lösen?

Danke für eure Hilfe und viele Grüße
JayDee

buntspexxt · January 30, 2025, 6:44pm

Du schreibst: "[...]scheinbar plötzlich so viele Anfragen [...]". Dein pihole denkt sich die Anfragen ja nicht aus, sondern bekommt von irgendwoher diese Requests.

Schritt 1 ist die Quelle der Requests zu finden und dort zu schauen, warum dort zu diesem Zeitpunkt so viele Anfragen gestellt werden.

JayDee · January 30, 2025, 8:36pm

Ich bin ein wenig überfragt was bzw wie genau ich das jetzt machen soll.
Über die Long-tern Data habe ich mir die Query Logs für den Zeitraum 13:45 bis14:15 gefiltert.

Über die Compute Top Lists from the Pi-hole query database konnte ich in diesem Zeitraum noch folgendes erkennen.

Top Client war mein Firmenlaptop mit insgesamt 7903 Requets in diesem Zeitraum. Allerdings habe ich das Laptop im Client group management aus den Adlists raus genommen.

rdwebdesign · January 30, 2025, 9:12pm

Maybe you can just click on a bar (in the dashboard graphic) to show the queries made in that specific time interval.

You can simply look at the table and try to find out which client is making the increased amount of queries. Also, check if there are one domain (or a few domains) being queried over and over.

JayDee · January 30, 2025, 9:20pm

Vielen Dank für deine Tipps. Nach einigem probieren, komme ich besser in das Auswerten der Long-term Data rein. In dem Zeitraum hat es folgende Anfragen gegeben:

In Summe erscheint mit das als Laie aber nicht wirklich auffällig oder? Plex und Microsofrt wurde relativ häufg geblockt. Aber ist das jetzt soviel, dass das pihole bzw. den RP5 so in die Knie zwingt?

buntspexxt · January 31, 2025, 11:17am

Das kommt darauf an. Wenn die Requests alle innerhalb einer kurzen Zeitspanne ankommen, dann ja. Schau dir mal die 172.24.1.47 und die .20 genauer an.

netswipe · February 9, 2025, 10:39pm

Ich habe das gleiche Problem. In der Zeit ist dann die pi.hole weboberfläche nicht verfügbar und die app geht nicht. Ich komme aber per ssh auf den pi. Ich denke dass das ein softwareproblem ist und gar nichts mit dem tatsächlichen traffic zutun hat.

Gibt übrigens noch jemanden der das Problem hat:

JayDee · February 10, 2025, 7:22am

Der Post ist auch von mir. :-/
Ich hatte den aber ehrlicherweise gar nicht mehr auf dem Schirm...

Bucking_Horn · February 10, 2025, 7:58am

Bitte lade ein Debug Log hoch und poste hier anschließend nur die Token-URL.
Das Token generierst Du über

pihole -d

wobei Du die Frage nach dem Upload bejahst, oder Du machst das über die Weboberfläche:
Tools > Generate Debug Log

JayDee · February 10, 2025, 8:21am

Hab es gerade über den Weg Tools > Generate Debug Log versucht und bekomme folgende Fehlermeldung:

[✗] There was an error uploading your debug log.

Please try again or contact the Pi-hole team for assistance.
A local copy of the debug log can be found at: /var/log/pihole/pihole_debug.log

Bevor ich das nochmal mache, macht es nicht mehr Sinn das zu machen wenn das Problem nochmal aufgetreten ist? Oder liefert das Debug Log noch die benötigten Informationen? Der Fehler war ja das letzte mal vor über 10 Tagen.

Bucking_Horn · February 10, 2025, 8:28am

Du kannst versuchen, diesen Fehler temporär zu umgehen, indem Du einen öffentlichen DNS-Server für Deinen Pi-hole-Rechner konfigurierst.

sudo nano /etc/resolv.conf

In dieser Datei ersetzt Du dann z.B. nameserver 127.0.0.1 durch z.B. nameserver 9.9.9.9, und nach Exit mit Save kannst Du den Upload erneut versuchen.

Ein Debug Log vom Zeitpunkt des beobachteten Ausfalls könnte sicherlich auch hilfreich sein, aber auch jetzt finden sich ggf. Hinweise auf mögliche Konfigurationen, die Deine Beobachtung begünstigen könnten.

JayDee · February 10, 2025, 8:37am

Hier die Token URL: https://tricorder.pi-hole.net/aoCkb5XP/

Kurz auf das DNS-Server Thema: Gibt es Vorteile oder Nachteile wenn ich in der /etc/resolv.conf einen öffentlichen DNS-Server eintrage? Ich hatte dort immer die pihole IP direkt eingetragen.

Bucking_Horn · February 10, 2025, 10:14am

Dein Debug Log sieht soweit unauffällig aus.
Conditional Forwarding ist nicht aktiv, so dass hierüber keine partielle DNS-Endlosschleife zustande kommen kann, und die Anbindung erfolgt nicht über WiFi, so dass es nicht zu Wifi-Störungen oder Wifi-Stromspar-Einstellungen kommen kann.

Allerdings unterstützt Dein Netzwerk link-lokales IPv6.
Was hast Du in Deiner Fritzbox in den IPv6-DNS-Einstellungen fürs Heimnetz eingestellt?

Es ist auf dem Pi-hole-Rechner von Vorteil, hier neben oder statt Pi-hole einen öffentlichen DNS-Server zu konfigurieren, da so Betriebssystem-Updates und Pi-holes Update- und Reparaturskripte auch im Falle eines Pi-hole-Ausfalls noch laufen können.

Auf allen anderen Rechnern muss Pi-hole der einzige DNS-Server sein.

JayDee · February 10, 2025, 10:19am

Glücklicher Zufall: Um 11:09 hatte ich wieder das Problem das keine Seiten mehr geöffnet werden konnten. Im Dashboard wird angezeigt, dass ~ 5000 queries angefallen sind. Ich habe driekt danach einen Debug Token erstellt. Hier der Link zum neuen Token: https://tricorder.pi-hole.net/6TRSjkgv/

IPv6 ist in der Fritzbox deaktiviert.

Bucking_Horn · February 10, 2025, 1:51pm

Das beantwortet nicht meine Frage:

Das findest Du unter Heimnetz»Netzwerk»Netzwerkeinstellungen»IPv6-Einstellungen: DNSv6-Server im Heimnetz.

In Deinem Debug Log taucht mehrfach folgende Meldung auf:

*** [ DIAGNOSING ]: contents of /var/log/pihole

-rw-r--r-- 1 pihole pihole 8.8K Feb 10 11:15 /var/log/pihole/FTL.log
   -----tail of FTL.log------
   [2025-02-10 11:08:46.324 1405M] WARNING in dnsmasq core: Maximum number of concurrent DNS queries reached (max: 150)
   [2025-02-10 11:08:55.185 1405M] WARNING in dnsmasq core: Maximum number of concurrent DNS queries reached (max: 150)
   [2025-02-10 11:09:01.287 1405M] WARNING in dnsmasq core: Maximum number of concurrent DNS queries reached (max: 150)
   [2025-02-10 11:10:33.718 1405M] WARNING in dnsmasq core: Maximum number of concurrent DNS queries reached (max: 150)>

Das sollte in Pi-holes Weboberfläche auch deutlich über einen Marker signalisiert und unter Tools | Pi-hole diagnosis angezeigt werden:

*** [ DIAGNOSING ]: Pi-hole diagnosis messages
 count  last timestamp      type                 message                                                     
 ------ ------------------- -------------------- ------------------------------------------------------------
 1      2025-02-10 11:10:33 DNSMASQ_WARN         Maximum number of concurrent DNS queries reached (max: 150)

Diese Warnung bezüglich der maximalen Anzahl gleichzeitiger DNS-Anfragen wird oft durch eine DNS-Endlosschleife ausgelöst.

Gelegentlich kann auch ein nicht erreichbarer oder nicht reagierender Upstream-DNS-Server dazu führen, dass Pi-Hole seinen Verbindungspool erschöpft, so dass zu viele DNS-Anfragen gleichzeitig auf eine Antwort von Upstream-Servern warten.

Und selten kann dass auch durch einen einzelnen Client passieren, der übermäßig viele DNS-Anfragen in rascher Folge stellt. In der Regel wird ein solcher Client aber bereits durch Pi-holes Rate limit ausgebremst.

Du könntest Dir die DNS-Anfragen, die einer Warnung unmittelbar vorausgehen, genauer ansehen, z.B. über folgendes Kommando:

pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db "SELECT domain, reply_type, client, count(*) FROM queries \
WHERE timestamp > strftime('%s','2025-02-10 11:08:46.324', '-3 minutes', 'utc') \
AND timestamp <= strftime('%s','2025-02-10 11:08:46.324', 'utc') \
GROUP BY domain, reply_type;"

JayDee · February 10, 2025, 2:21pm

Unter Heimnetz»Netzwerk»Netzwerkeinstellungen gibt es auf meiner Box (FB6591) keine IPv6 Einstellungen. Lediglich IPv4 Einstellungen. Die einzige Einstellung zu IPv6 kann ich unter Internet»Zugangsdaten»IPv6 machen und dort ist IPv6-Unterstützung deaktiviert.

Das Kommando das DNS-Anfragen, die der Warnung unmittelbar vorausgehen sieht für mich unauffällig aus. Kein Eintrag ist mehr als drei mal hintereinander aufgeführt. Oder muss ich auf irgendwas bestimmtes achten?

Was sagt z.B. die 12 am Ende dieses Eintrags aus:
ap-gew4.spotify.com|0|172.24.1.39|12
Sind das 12 versuchte Anfragen?

Bucking_Horn · February 10, 2025, 2:36pm

Genau, die von 172.24.1.39 gestellte Anfrage für ap-gew4.spotify.com wurde 12x mit reply_type 0 verarbeitet.

Wie sieht denn die gesamte Ausgabe für eine Abfrage aus?

JayDee · February 10, 2025, 2:44pm

Hier die gesamte Abfrage:

pi@RaspberryPI5:~ $ pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db "SELECT domain, reply_type, client, count(*) FROM queries \
WHERE timestamp > strftime('%s','2025-02-10 11:08:46.324', '-3 minutes', 'utc') \
AND timestamp <= strftime('%s','2025-02-10 11:08:46.324', 'utc') \
GROUP BY domain, reply_type;"

.|0|172.24.1.183|1
_32400._https.10-0-3-1.e1cd9b209c6e480b9641c47236d74af7.plex.direct|0|172.24.1.20|5
_32400._https.10-0-5-1.e1cd9b209c6e480b9641c47236d74af7.plex.direct|0|172.24.1.20|5
_32400._https.10-0-7-1.e1cd9b209c6e480b9641c47236d74af7.plex.direct|0|172.24.1.20|5
_32400._https.192-168-0-69.e1cd9b209c6e480b9641c47236d74af7.plex.direct|0|172.24.1.20|5
_5222._https.web.whatsapp.com|0|172.24.1.47|14
accounts.google.com|1|172.24.1.20|1
accounts.google.com|4|172.24.1.20|3
accounts.youtube.com|0|172.24.1.20|1
accounts.youtube.com|3|172.24.1.20|4
ap-gew4.spotify.com|0|172.24.1.39|12
ap-gew4.spotify.com.fritz.box|0|172.24.1.39|4
ap.spotify.com|0|172.24.1.21|6
api.amazonalexa.com|3|172.24.1.33|2
api.eu.amazonalexa.com|0|172.24.1.33|10
api.eu.amazonalexa.com|3|172.24.1.31|3
api.eu.amazonalexa.com.fritz.box|0|172.24.1.33|1
api.gcs.garmin.com|0|172.24.1.126|1
api.gcs.garmin.com|3|172.24.1.126|1
api.spotify.com|0|172.24.1.183|2
api.spotify.com|3|172.24.1.183|3
arcus-uswest.amazon.com|0|172.24.1.45|6
arcus-uswest.amazon.com.fritz.box|0|172.24.1.45|5
atm-fp-direct.office.com|3|172.24.1.47|1
avs-alexa-6-eu.amazon.com|0|172.24.1.45|2
avs-alexa-6-eu.amazon.com.fritz.box|0|172.24.1.45|2
calendar.google.com|0|172.24.1.47|1
calendar.google.com|1|172.24.1.20|1
calendar.google.com|4|172.24.1.20|4
checkonline.home-assistant.io|0|172.24.1.183|1
checkonline.home-assistant.io|4|172.24.1.183|1
community.simon42.com|0|172.24.1.20|5
community.simon42.com|1|172.24.1.20|1
connectivitycheck.gstatic.com|0|172.24.1.39|4
connectivitycheck.gstatic.com.fritz.box|0|172.24.1.39|1
d3p8zr0ffa9t17.cloudfront.net|4|172.24.1.36|3
data.meethue.com|0|172.24.1.22|22
device-messaging-na.amazon.com|4|172.24.1.33|4
device-metrics-us.amazon.com|4|172.24.1.30|3
diag.meethue.com|3|172.24.1.22|4
dp-gw-na.amazon.com|0|172.24.1.45|2
dp-gw-na.amazon.com.fritz.box|0|172.24.1.45|2
easylist-downloads.adblockplus.org|1|172.24.1.20|1
easylist-downloads.adblockplus.org|4|172.24.1.20|3
ec56d883b8f24b96aec07e1813be355f.fp.measure.office.com|0|172.24.1.47|1
ec56d883b8f24b96aec07e1813be355f.fp.measure.office.com|4|172.24.1.47|1
eu-mobile.events.data.microsoft.com|3|172.24.1.109|2
eu-v20.events.data.microsoft.com|0|172.24.1.47|9
eu-v20.events.data.microsoft.com|3|172.24.1.47|3
europe.cp.wd.microsoft.com|3|172.24.1.47|2
europe.smartscreen.microsoft.com|0|172.24.1.47|9
europe.smartscreen.microsoft.com|3|172.24.1.47|3
exo.nel.measure.office.net|0|172.24.1.47|18
fireoscaptiveportal.com|4|172.24.1.36|1
firetvcaptiveportal.com|0|172.24.1.45|2
firetvcaptiveportal.com.fritz.box|0|172.24.1.45|1
go-eu.trouter.teams.microsoft.com|0|172.24.1.47|18
ingest.datax.activision.com|3|172.24.1.20|1
login.microsoftonline.com|3|172.24.1.47|1
lsg.7300.prod.demonware.net|0|172.24.1.20|10
mmechocaptiveportal.com|4|172.24.1.33|2
mqtt-eu-02.iot.meethue.com|1|172.24.1.22|1
mqtt-eu-02.iot.meethue.com|4|172.24.1.22|1
msh.amazon.co.uk|0|172.24.1.45|4
msh.amazon.co.uk.fritz.box|0|172.24.1.45|2
msh.amazon.com|0|172.24.1.21|6
mtalk.google.com|3|172.24.1.35|1
ncsi.qnap.com|3|172.24.1.10|1
onedscolprdneu08.northeurope.cloudapp.azure.com|1|172.24.1.109|1
optimizationguide-pa.googleapis.com|1|172.24.1.47|1
optimizationguide-pa.googleapis.com|4|172.24.1.47|1
ot.io.mi.com|0|172.24.1.28|2
ot.io.mi.com|1|172.24.1.28|3
ot.io.mi.com|4|172.24.1.28|2
outlook.office.com|0|172.24.1.47|40
outlook.office365.com|0|172.24.1.47|4
outlook.office365.com|3|172.24.1.47|2
partition-cname-trouter-ic3-edf-trouter-service-trouter-2.d02-009.ic3-edf-trouter.01-germanywestcentral-prod.cosmic.office.net|1|172.24.1.109|1
pindorama-eu.amazon.com|0|172.24.1.30|2
pindorama-eu.amazon.com.fritz.box|0|172.24.1.30|1
play.google.com|0|172.24.1.47|8
presence.teams.microsoft.com|3|172.24.1.47|2
profile.accounts.firefox.com|4|172.24.1.20|1
pubsub.plex.tv|4|172.24.1.20|10
r4.res.office365.com|3|172.24.1.47|1
rest-hw-e001.immedia-semi.com|0|172.24.1.29|27
rta.xboxlive.com|0|172.24.1.20|5
signaler-pa.clients6.google.com|1|172.24.1.20|1
srv0057.a.homematic.com|0|172.24.1.183|14
srv0057.a.homematic.com|8|172.24.1.38|1
ssl.gstatic.com|4|172.24.1.20|3
statics.teams.cdn.office.net|0|172.24.1.47|24
svcs.myharmony.com|0|172.24.1.32|2
svcs.myharmony.com|3|172.24.1.32|3
teams.microsoft.com|0|172.24.1.47|28
teams.microsoft.com|3|172.24.1.47|1
telescope.callofduty.com|0|172.24.1.20|3
time.android.com|0|172.24.1.42|2
upload.fp.measure.office.com|3|172.24.1.47|1
waa-pa.clients6.google.com|0|172.24.1.20|1
waa-pa.clients6.google.com|1|172.24.1.20|1
waa-pa.clients6.google.com|4|172.24.1.20|3
waconatm.officeapps.live.com|3|172.24.1.47|1
web.whatsapp.com|0|172.24.1.20|68
winatp-gw-weu.microsoft.com|3|172.24.1.47|1
wpad.fritz.box|2|172.24.1.20|2
www.google-analytics.com|0|172.24.1.47|8
www.perplexity.ai|0|172.24.1.20|5
www3.l.google.com|4|172.24.1.20|2
youtube-ui.l.google.com|0|172.24.1.20|5

Bucking_Horn · February 10, 2025, 3:20pm

Das 3-Minuten-Intervall ist hier eventuell zu groß, so dass man vielleicht auch auf '-30 seconds' verkleinern könnte.

Aber man sieht auch so bereits, dass sehr viele (~450 von ~560) Anfragen mit reply_type 0 protokolliert wurden. 0 steht hier für unbekannt (Antwort steht aus), d.h. Pi-hole hat hier auf die Antwort eines Upstream gewartet, aber nie eine erhalten.

Dies würde auf eine kurzzeitige Nicht-Verfügbarkeit eines von Pi-holes Upstreams hindeuten.

Der verwendete Upstream (forward) sollte sich ebenfalls ermitteln lassen.
Was gibt folgendes SQL-Kommando zurück:

pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db "SELECT status, forward, count(*) FROM queries \
WHERE timestamp > strftime('%s','2025-02-10 11:08:46.324', '-30 seconds', 'utc') \
AND timestamp <= strftime('%s','2025-02-10 11:08:46.324', 'utc') \
AND reply_type = 0 GROUP BY status, forward;"

Weisen die Kommandos denn zu den anderen Zeitpunkten ebenfalls gehäuft reply_status 0 aus?

JayDee · February 10, 2025, 4:18pm

Hier das Ergebnis:

0||77
2|149.112.112.11#53|263
12|149.112.112.11#53|37
14||26

Ob Kommandos zu den anderen Zeitpunkten ebenfalls gehäuft reply_status 0 ausweisen muss ich mal prüfen.