Merkwürdiges Verhalten von PiHole

Hallo zusammen,

ich habe PiHole letzte Woche in Proxmox in einem LXC installiert.
Von beginn an, verhält sich das PiHole sehr merkwürdig und ich kann den Grund nicht finden.

Ich bekomme sporadisch bei den DNS Abfragen N/A zurück. Das Verhalten ist vollkommen zufällig, zumindest konnte ich kein Muster erkennen. Die gleiche Abfrage geht Sekunden später sauber durch.

Dann habe ich auf Proxmox diverse Container laufen, die auch, ebenfalls ohne erkennbares Muster, hinter die DNS Abfrage ein .local hängen und dann natürlich vor die Wand laufen.
Wo das .local her kommt habe ich inzwischen rausgefunden, aber nicht warum das kommt. Es erscheint nämlich nicht bei jeder Abfrage.

Ich habe verschiedene DNS Server versucht (google, Quad9, etc) auch in Kombination. Gleiches ergebnis.
DNS Anfragen vom Client direkt, oder über den Router, gleiches Ergebnis.

Bitte lade ein Debug Log hoch und poste hier anschliessend nur das Token.
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

Dass Clients eine Suchabfrage um die lokale Domäne/Suchdomäne/search suffix ergänzen, ist nicht ungewöhnlich. Allerdings sollte .local als lokaler Domänenname vermieden werden, da die Verwendung von .local für das mDNS-Protokoll reserviert ist.
Du solltest Dein Netzwerk auf eine andere lokale Domäne konfigurieren.

Das hat höchstwahrscheinlich keine Auswirkung auf Deine erste Beobachtung.
Neben dem Debug Log wäre hier auch interessant, wie die Ausgabe für ein dig auf eine der Domänen während des Retried-Zeitraums aussieht.

Hi,

hier der Token.

https://tricorder.pi-hole.net/69oi7kdz8i

das .local hatte ich nur zu Testzwecken dort eingetragen.
Ursprünglich war es .fritzbox, hat aber das gleiche Verhalten ausgelöst.

was ist mit einem "dig" gemeint ?

Edit: War gerade 20min auf Amazon am surfen und plötzlich ging nichts mehr. Alle DNS Abfragen zu Amazon und sogar hier das Forum, kamen mit N/A zurück.

So ist das PiHole nicht nutzbar.
DIe Ausfälle sind komplett zufällig. Beschränkt sich nicht auf bestimmte Sites oder Uhrzeiten.

Das Verhalten in Bezug auf die Suchdomäne ist ja auch normal, nur handelst Du Dir mit .local ggf. Schwierigkeiten ein, da...


Dein Debug Log sieht soweit unauffällig aus, bis auf die folgenden Meldungen:

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

-rw-r--r-- 1 pihole pihole 2196 Jun 16 06:03 /var/log/pihole-FTL.log
   -----head of pihole-FTL.log------
   [2021-06-16 03:50:04.951 20956M] FATAL: Trying to access query ID -1, but maximum is 61440
   [2021-06-16 03:50:04.951 20956M]        found in FTL_query_in_progress() (/root/project/src/dnsmasq_interface.c:2181)
   [2021-06-16 03:50:04.951 20956M] Failed to unlock SHM lock: Operation not permitted

Diese Fehlermeldung ist in FATAL: Trying to access query ID -1 errors in pihole-FTL.log - #13 by DL6ER bereits untersucht worden und eigentlich in dem Zusammenhang auch behoben.

Nach der dortigen Beschreibung hat dieser Fehler allerdings auch ohne Behebung lediglich zu zusätzlichen Log-Einträgen ohne negative Seiteneffekte geführt.

Ich werde dazu eine Frage an das Entwickler-Team stellen.


dig ist ein Kommandozeilen-Tool, das DNS-Anfragen auslösen und Antworten anzeigen kann, ähnlich wie nslookup. Im Unterschied zu diesem kann dig aber detailiertere Informationen ausgeben.

Retried bedeutet, dass ein Client eine identische DNS-Anfrage an Pi-hole stellt, die Pi-hole bereits zuvor an einen seiner Upstream-DNS-Server weitergeleitet hat. Dessen Antwort steht allerdings noch aus. Deshalb zeigt Pi-holes Query Log hier als Antwort auch N/A, was bei Retried eben soviel bedeutet wie "Antwort steht noch aus".

Entweder wiederholt ein ungeduldiges Stück Software auf dem Client die Anfrage zu häufig, oder der Upstream-DNS-Server lässt sich einfach besonders lange Zeit mit seiner Antwort.
Wenn Du testweise möglichst nur einen Upstream-DNS-Server in Pi-hole konfigurieren würdest, könnte das helfen, das besser eingrenzen zu können.

Eine Ausgabe von dig zum Zeitpunkt der Retried-Einträge würde im Vergleich mit einer weiteren Anfrage an den verwendeten öffentlichen DNS-Server ggf. weitere Rückschlüsse ermöglichen.

Dazu solltest Du die folgenden Kommandos ausführen, wenn das nächste Mal eine Serie von Retried -Anfragen auftritt.

dig <auffällige.domain> @192.168.2.14
dig <auffällige.domain> @208.67.222.222

<auffällige.domain> ist dabei durch die konkret wiederholt angefragte Domain zu ersetzen (also für Deine obigen Bildschirmfotos z.B. auf dig updates2.signal.org @192.168.2.14).
Im zweiten Kommando ist 208.67.222.222 ggf. durch den aktuell verwendeten Upstream-DNS-Server zu ersetzen.

N/A steht in diesem Kontext für "Not available" und heißt, dass es bislang keine Antwort vom DNS Server gegeben hat. Wenn das passiert wären die Zeilen in der Datei /var/log/pihole.log zu diesem Zeitpunkt interessant. Hier kann man vermutlich sehen, dass nichts von Deinem gewählten DNS Server zurück kam.

  • Kann es sein, dass es temporäre Internetprobleme gab?
  • Könntest Du wenn es wieder auftritt einen ping zu dem von Dir gewählten DNS Server probieren?
  • Könntest Du temporär einen anderen DNS Server probieren?

Ich hatte ähnliche Probleme mit der Fritzbox 7590 wo zeitweise das DSL abhanden kam ohne dass die Fritzbox es in der grafischen Oberfläche vermeldet hat. Ich habe dann ein geschirmtes Kabel statt des normalen Telefonkabels verlegt und meine Probleme waren behoben. (das nur als Randnotiz)

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