Ich bekomme regelmäßig Meldungen in der Pi-hole diagnosis wie diese hier:
Ich habe ein Log hoch geladen und ein debug Token erzeugt: https://tricorder.pi-hole.net/F4ejYGw1/
Ich habe ein Log hoch geladen und ein debug Token erzeugt: https://tricorder.pi-hole.net/F4ejYGw1/
Diese beiden Meldungen könnten zusammenhängen:
Wenn das Netzwerk eines DNS-Servers nicht erreichbar ist (Network unreachable), würden sich die DNS-Anfragen in Pi-hole sehr schnell so stark anstauen, bis kein Platz mehr in der Warteschlange ist (Maximum number of concurrent DNS queries reached).
Typischerweise tritt der erste Fehler auf, wenn Dein Netzwerk IPv6 nicht unterstützt.
Das ist laut Debug Log bei Dir nicht der Fall, zumindest nicht prinzipiell oder dauerhaft:
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] melissapoland.com is NOERROR on lo (::1)
[✓] melissapoland.com is NOERROR on end0 (2a02:<redacted>c3)
[✓] melissapoland.com is NOERROR on end0 (fe80::<redacted>d5%end0)
[✓] doubleclick.com is 2a00:1450:4007:80d::200e via a remote, public DNS server (2001:4860:4860::8888)
Trotzdem könntest Du versuchen, ob die Meldungen nach Abwahl der IPv6-Server aus der Liste von Pi-holes Upstream DNS Servern nicht mehr auftauchen.
Unabhängig von den von Dir beobachteten Fehlermeldungen zeigt Dein Debug Log außerdem, dass Deine Fritzbox ihre eigene IPv4-Adresse als lokalen DNS-Server verteilt:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 6 seconds)
Scanning all your interfaces for DHCP servers and IPv6 routers
* Received 548 bytes from 192.168.1.2 @ end0
Offered IP address: 192.168.1.12
DHCP options:
Message type: DHCPOFFER (2)
router: 192.168.1.2
dns-server: 192.168.1.2
Fritzboxen können Pi-holes IP-Adresse als lokalen DNS-Server verteilen, siehe Fritz!Box (DE) - Pi-hole documentation.
Außerdem annonciert die Fritzbox auch ihre eigenen IPv6-Adressen als lokale DNS-Server, so dass IPv6-Clients Pi-hole vollständig umgehen können.
Das lässt sich abstellen, z.B. (Proxmox) DNS Probleme nach Stromausfall - #4 by Bucking_Horn.
Herzlichen Dank für die ausführliche Hilfe, ich habe es entsprechend umgesetzt und werde es beobachten. Was mir nur aufgefallen ist: In der Pi-hole Dokumentation ist beschrieben, wie man die IPv6 Adresse des Pi-hole als "Lokaler DNSv6-Server" eintragen kann, in dem verlinkten Forenbeitrag steht aber, dass "DNSv6-Server auch über Router Advertisement bekanntgeben (RFC 5006)" in der Fritzbox abgewählt werden sollte. Ich bin nun so vorgegangen, wie das in der Dokumentation steht und hoffe, dass ich keinen Fehler gemacht habe. Wenn ich das richtig verstanden habe, habe ich ja nun eine geänderte IPv6 Adresse (nämlich die des Pi-hole) eingetragen. Ist das richtig?
Beide Konfigurationen funktionieren.
Wenn allerdings IPv6-fähige Clients eine IPv6-Adresse eines DNS-Servers kennen, werden sie DNS-Anfragen bevorzugt über IPv6 stellen.
Da IPv6-Clients oft regeImässig ihre IID ändern (z.B. alle zwei Stunden), wird sich Pi-holes Query Log dann recht schnell mit DNS-Anfragen von unterschiedlichen IPv6-Client-IPs fülllen, und da IPv6-Clients nicht notwendigerweise einen Hostnamen über DHCPv6 angeben, können diese auch oft nicht zuverlässig namentlich zugeordnet werden.
Durch das Abschalten von IPv6-DNS-Server-Adressen stellen Clients DNS-Anfragen nur noch über IPv4, wodurch das Query Log übersichtlicher bleibt.
Network unreachable ist derselbe wie zuvor - Du hast Du die IPv6-Server aus der Liste von Pi-holes Upstream DNS Server also noch nicht abgewählt.
169.254.120.237 ist eine link-lokale IPv4-Adresse.
Solche Adressen werden von einem Client normalerweise nur verwendet, wenn dieser keine IPv4 über DHCP beziehen konnte.
Dies könnte auf ein generelles Netzwerkproblem hindeuten:
Wenn Dein Pi-hole-Rechner tatsächlich bisweilen seine Netzwerkverbindung verliert, würde eine solche LLA auftauchen, und das könnte auch Network unreachable erklären.
Wie ist Dein RPi 5 mit dem Router verbunden?
OK, das stimmt, IPv6-Server waren noch nicht abgewählt. Nun sind sie aber raus und Network unreachable erscheint nicht mehr.
Nur die 169.254.120.237 Warnung taucht nach wie vor auf. Der Pi-hole verliert seine Netzwerkverbindung nicht, er ist über LAN an einem Switch angeschlossen, der eine LAN-Verbindung zum Router hat.
Was auch nicht funktioniert: Ich kann Pi-hole nicht über eine gesicherte Verbindung über das HTTPS-Protokoll aufrufen. https://pi.hole kann nicht gefunden werden. Das Zertifikat tls_ca.crt habe ich in den Browser importiert, es wird in den Einstellungen auch angezeigt.
Kann das damit zu tun haben, dass der Hostname meines RPi 5 raspberrypi ist? Das möchte ich so lassen, weil auch noch andere Software auf dem RPi läuft. Ich habe aber auch keine Möglichkeit gefunden, wie ich das im Zertifikat ändern könnte.
Ist es ok, wenn ich das hier mit anspreche oder soll ich dafür einen eigenen Thread aufmachen?
Gesicherte Verbindung unter https://raspberrypi/ funktioniert! Ich habe den Hostnamen raspberrypi unter webserver.domain eingetragen und dns.piholePTR geändert.
Anschließend mit sudo rm /etc/pihole/tls* && sudo service pihole-FTL restart ein neues Zertifikat erstellt und im Browser importiert.
Pi-hole ist hier nicht involviert, es stellt nur fest, dass solche Anfragen eingehen.
Es ist dabei hochgradig wahrscheinlich, dass 169.254.120.237 die selbstgewählte LLA des Rechners ist, auf dem Pi-hole läuft. Theoretisch könnten die entsprechenden Anfragen auch von einem anderen Gerät kommen, allerdings hätte ein solches Gerät ohne korrektes DHCP-Lease keine Kenntnis von einer DNS-Server-IP-Adresse.
Eine oberflächliche Suche ergibt einige Meldungen bezüglich unzuverlässiger Ethernet-Schnittstellen-Erkennung (z.B. Raspberry Pi 5 sometimes has no LAN connection after booting · Issue #6420 · raspberrypi/linux · GitHub), speziell für 5er RPis, die unter RPiOS 12/Bookworm laufen.
Möglicherweise ist EEE (Energy Efficient Ethernet) involviert, das die Ethernet-Schnittstelle nach einer gewissen Zeit ohne Aktivität in den Energiesparmodus versetzt.
Sollte das der Fall sein, könntest Du versuchen, EEE auf dem Pi-hole-Rechner abzuschalten:
sudo ethtool --set-eee end0 eee off
Sofern Du sonst keine Beeinträchtigungen beobachtest, kannst Du diese Meldung auch ignorieren.
Für weitergehende Untersuchungen zu sporadischen Ethernet-Problemen solltest Du darauf spezialisierte Foren besuchen.
Habe ich versucht: netlink error: Operation not supported
Nun ist noch eine zweite Meldung hinzu gekommen:
Ich habe schon die erlaubte Anzahl von (default) 150 auf 200 rauf gesetzt.
Teste doch mal bitte, ob die fe80 Adresse des Pi in die IPv6 Konfiguration der Fritzbox einzutragen.
Diese Einstellung läuft bei mir zwischen Pi und Fritzbox seit langer Zeit und beiden Pi-Hole Versionen stabil, denn diese IPv6 Adresse ist aus meiner Erfahrung die einzige, die sich nicht ändert im Gegensatz dazu 2003/2001/fd00/fd28 Adressen, die sich immer wieder verändern. Die Historie ab IPv6 Adressen findest du bei jedem Client in der Fritzbox.
Wo muss ich das eintragen, hier:
DNSv6-Server im Heimnetz
DNSv6-Server auch über Router Advertisement bekanntgeben (RFC 5006)
Das stimmt dann stellenmäßig aber nicht mit dem überein, was mir beim RPi 5 angezeigt wird:
IPv6-Adressen fe80::xxxx:xxxx:xxxx:xxxx
Eintragen muss ich: fe80:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
Dann hast du dich wohl verguckt oder verschrieben 
Die fe80 Adresse findest du auch in der Fritzbox. Da kann man sie auch einfach kopieren.
Die nachstehende reduzierte Notation mit ::
ist identisch zu
Der erste bis dritte xxxx-Block ist dabei 0000.
Diese von wd9895 vorgeschlagene Änderung hätte aber keinen Bezug zu Deinen Fehlermeldungen.
Wie erwähnt, kann Maximum number of concurrent DNS queries reached auftreten, wenn sich DNS-Anfragen in Pi-hole aufstauen.
Das kann z.B. passieren, wenn Pi-holes Upstream-DNS-Server nicht antworten oder nicht erreichbar sind, was wiederum bei zeitweise auftretenden Verbindungsproblemen der Fall wäre. Das Auftreten einer IPv4-LLA ist zumindest ein Hinweis auf Verbindungsprobleme.
Du solltest diesbezüglich die Syslogs auf Deinem Pi-hole-Rechner untersuchen.
Eine weitere Ursache für die Warnung wäre eine DNS-Endlosschleife, bei der Pi-hole DNS-Anfragen an einen Router schickt, der seinerseits DNS-Anfragen an Pi-hole sendet.
Eine solche DNS-Schleife kann z.B. durch Anschalten von Pi-holes Conditional Forwarding partiell geschlossen werden.
Bitte stell ein frisches Debug Token ein.
Ich glaube, ich habe das Gerät, das für die die 169.254.120.237 Warnung verantwortlich ist identifiziert. Es bekommt nämlich i.d.R. eine lokale IP-Adresse, allerdings ist es über WLAN eingebunden und diese Verbindung ist nicht sehr stabil. Ich habe öfter Probleme mit der Erreichbarkeit, es ist eine Homekit-Steckdose von Meross. Ich konnte sie mit Hilfe von Pi-hole Remote lokalisieren.
Hier ist noch einmal ein aktuelles Debug Token: https://tricorder.pi-hole.net/WeJRROms/
Die möglichen Ursachen für Maximum number of concurrent DNS queries reached habe ich bereits erläutert.
Die Existenz von Webseiten hat keinen Einfluss auf DNS.
Über Ostern ist Dein Debug Token abgelaufen, bitte stell nochmal ein neues ein.
OK, gerne: https://tricorder.pi-hole.net/N86fKDRm/
Das Nichtmehr-Existieren der Webseite ist natürlich nicht ursächlich, ich denke aber, dass die vielen Anfragen eines anderen RPi im Netz der Grund dafür waren. Dieser hat nämlich sehr geschwätzig Daten an mqtt.mydevices.com senden wollen und diese Seite gibt es nicht mehr. Als workaround habe ich mqtt.mydevices.com geblockt und seitdem kommt Maximum number of concurrent DNS queries reached nicht mehr. Damit habe ich aber selbstverständlich noch nicht die Ursache abgestellt, dazu muss ich erst noch auf die Suche bei dem anderen RPi gehen. Mache ich, wenn ich mal wieder mehr Zeit habe, erstmal geht es so.
Das Drehen an dns-forward-max bringt in der Regel nichts.
Es behebt nicht die Ursache und führt höchstens dazu, dass die Warnung ein paar Millisekunden später auftritt.
Wie erwähnt, wird diese durch nicht erreichbare Upstream-DNS-Server oder durch eine DNS-Schleife verursacht, seltener durch einzelne sich fehlverhaltende Clients.
Deine letzte max concurrent-Warnung listet eine Rückwärts-Anfrage aus dem Bereich 192.168.1.0/24.
Dein Debug Log zeigt, dass Du Pi-holes Conditional Forwarding für diesen Bereich aktiviert hast:
revServers = [
"true,192.168.0.0/24,192.168.1.2,fritz.box"
] ### CHANGED, default = []
Conditional Forwarding kann eine partielle DNS-Schleife schliessen, wenn Dein Router gleichzeitig Pi-hole als Upstream verwendet - in der Fritzbox wären das die Einträge unter Internet | Zugangsdaten | DNS-Server.
Da Deine Fritzbox Pi-holes IPv4 bereits als lokalen DNS-Server via DHCP verteilt, solltest Du als Upstream der Fritzbox also die vom Internetanbieter zugewiesenen DNS-Server verwenden.
Außerdem annonciert Deine Fritzbox immer noch ihre eigenen IPv6-Adressen als lokale DNS-Server:
* Received 176 bytes from fe80::3631:c4ff:fe57:2340 @ end0
(…)
- Prefix: 2a<redacted>::/64
Valid lifetime: 7200 sec
Preferred lifetime: 3600 sec
On-link: Yes
Autonomous address conf.: Yes
- Prefix: fd3f:<redacted>::/64
Valid lifetime: 7200 sec
Preferred lifetime: 3600 sec
On-link: Yes
Autonomous address conf.: Yes
Recursive DNS server 1/2: fd3f:<redacted>40
Recursive DNS server 2/2: 2a<redacted>40
Das solltest Du wie bereits beschrieben abstellen, damit IPv6-Clients Pi-hole nicht vollständig umgehen.
Unabhängig von der Warnung solltest Du Deine Group Management-Einstellungen überdenken.
Dein Debug Log zeigt, dass Du knapp 50 Clients in Pi-hole angelegt hast.
Eingehende DNS-Anfragen werden von Pi-hole standardmässig immer über die Default-Gruppe gefiltert.
Das Anlegen eines Clients ist nur erforderlich und sinnvoll, wenn Du diesen client-spezifisch filtern möchtest.
Du hast jedoch außer der Default-Gruppe keine weitere Gruppe für client-spezifische Filter angelegt, und Deine Clients werden ausnahmslos alle über die Default-Gruppe gefiltert.
Die Client-Definitionen sind damit überflüssig und können entfernt werden.
1 Like
Wenn ich das mache bei ansonsten gleich gebliebenen Einstellungen, werden keine Ads mehr blockiert, alle Werbung kommt durch. Deshalb hatte ich das wieder geändert.
Hatte ich abgewählt und ist auch weiterhin so eingestellt.
Das hatte ich gemacht, damit ich sehe, von welchem Client die Anfragen tatsächlich kommen. Es sah nämlich voerher so aus, als ob alle Anfragen von der Fritzbox kämen.
Im übrigen sind nun nach einiger Betriebszeit mit denselben Einstellungen keine Warnungen mehr aufgetreten. Ich schalte nun Conditional Forwarding mal aus.