Hallo,
nach dem Update auf die neuen Versionen pi-hole 5.7 / FTL 5.12.1 / Web 5.9 habe ich das erstmal nachfolgende Warnung bekommen.
Muss ich da etwas machen oder wie gehe ich damit um?
DNSMASQ_WARN Warning in dnsmasq core:
Maximum number of concurrent DNS queries reached (max: 150)
Danke
Hallo aber haben die Antworten auch etwas mit meiner Fehlermeldung zu tun?
Danke für den Einwand, ich hatte nicht bemerkt, dass sich da noch jemand zwischengeklinkt hatte.
Das denke ich nicht. Durch eine Änderung on der aktuellen Version wurden sie lediglich besser sichtbar gemacht, indem sie u.A. auf dem Dashboard angezeigt werden:
Die Warnungen sind hier dokumentiert (die Dokumentation wächst noch während wir immer mehr konkrete Fälle bei Nutzern entdecken): dnsmasq warnings - Pi-hole documentation
In Deinem konkreten Fall wird die Warnung auch schon immer da, nur eben nicht sichtbar gewesen sein. Wenn Du in der Datei /var/log/pihole.log schaust und nach den Einträgen unmittelbar vor dieser Warnmeldung schaust, dürftest Du herausfinden, woran das liegt.
Wir können das dann mit einem Logausschnitt auch gerne zusammen herausfinden, ohne ist das aber nur wildes Raten.
Hallo und so sieht der Log davor aus.
Dec 26 21:49:03 dnsmasq[31442]: Maximum number of concurrent DNS queries reached (max: 150)
Dec 26 21:49:03 dnsmasq[31442]: config error is REFUSED
Dec 26 21:49:03 dnsmasq[31442]: query[AAAA] wsh.prod.coms.connect.axis.com from 192.168.178.240
Dec 26 21:49:03 dnsmasq[31442]: config error is REFUSED
Dec 26 21:49:03 dnsmasq[31442]: query[A] wsh.prod.coms.connect.axis.com from 192.168.178.240
Dec 26 21:49:03 dnsmasq[31442]: config error is REFUSED
Dec 26 21:49:03 dnsmasq[31442]: query[AAAA] wsh.prod.coms.connect.axis.com from 192.168.178.240
Dec 26 21:49:03 dnsmasq[31442]: config error is REFUSED
Wie weit wird denn der Log davor benötigt?
Naja, das sind doch die Zeilen danach, oder?
Irgendetwas sagt mir jedoch, dass die Zeilen davor vermutlich identisch ausstehen - alles steht im Zusammenhang mit der Domain
wsh.prod.coms.connect.axis.com
Wie oft kommen diese Anfragen? Sind das hunderte/tausende pro Minute?
Hier nun alles was in dieser Zeiteinheit passiert ist:
Dec 26 21:49:03 dnsmasq[31442]: query[A] se-eu.accws.axis.com from fd00::f95b:1fd4:6576:52a3
Dec 26 21:49:03 dnsmasq[31442]: forwarded se-eu.accws.axis.com to 127.0.0.1
Dec 26 21:49:03 dnsmasq[31442]: query[A] se-eu.accws.axis.com from 192.168.178.121
Dec 26 21:49:03 dnsmasq[31442]: forwarded se-eu.accws.axis.com to 127.0.0.1
Dec 26 21:49:03 dnsmasq[31442]: query[A] wsh.prod.coms.connect.axis.com from 192.168.178.240
Dec 26 21:49:03 dnsmasq[31442]: Maximum number of concurrent DNS queries reached (max: 150)
Dec 26 21:49:03 dnsmasq[31442]: config error is REFUSED
Dec 26 21:49:03 dnsmasq[31442]: query[AAAA] wsh.prod.coms.connect.axis.com from 192.168.178.240
Dec 26 21:49:03 dnsmasq[31442]: config error is REFUSED
Dec 26 21:49:03 dnsmasq[31442]: query[A] wsh.prod.coms.connect.axis.com from 192.168.178.240
Dec 26 21:49:03 dnsmasq[31442]: config error is REFUSED
Dec 26 21:49:03 dnsmasq[31442]: query[AAAA] wsh.prod.coms.connect.axis.com from 192.168.178.240
Dec 26 21:49:03 dnsmasq[31442]: config error is REFUSED
Wie viele das sind kann ich nicht sagen aber das kommt schon oft vor.
Aha, das ist etwas anderes. Was für ein DNS Server steht hinter der IP-Adresse 127.0.0.1? Hast Du einen lokalen unbound o.Ä. am Laufen? Dieser Server scheint nicht zu laufen bzw. zumindest nicht zu antworten.
Ja richtig ist nutze unbound
Bitte überprüfe ob der läuft bzw. wieso er nicht antwortet.
Ups ok da muss ich mich wieder reinarbeiten ist schon länger her 
pi@rpi4-pi-hole:~ $ systemctl status unbound.service
● unbound.service - Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset:
Active: active (running) since Thu 2021-12-23 19:22:46 CET; 3 days ago
Docs: man:unbound(8)
Main PID: 581 (unbound)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/unbound.service
└─581 /usr/sbin/unbound -d
Dez 27 13:47:45 rpi4-pi-hole unbound[581]: [581:0] info: generate keytag query _
Warning: Journal has been rotated since unit was started. Log output is incomple
lines 1-11/11 (END)
Ich werde dann mal die Fehlermeldung im pi-hole löschen und nicht weiter beachten, da es wohl nur ein sporadischer Fehler war.
(Ein großer Wunsch wäre von mir, wenn unbound in Pi-hole integriert wäre bzw. man darüber konfigurieren könnte.)
Nun bekomme ich noch nachfolgende Meldung:
2021-12-30 00:25:49 DNSMASQ_WARN Warning in dnsmasq core:
reducing DNS packet size for nameserver 127.0.0.1 to 1280
Ich habe mir DNSMASQ_WARN reducing DNS packet size versucht durchzulesen aber da englisch nicht meine Muttersprache ist und dann auch noch bei so einem Thema, fällt es mir schwer, daraus Antworten abzuleiten.
Was sollte ich denn bei mir mit meinem unbound PI-hole machen, damit nicht ständig die Warnungen erscheinen?
Du erstellst eine Datei, z.B. /etc/dnsmasq.d/99-edns.conf und schreibst folgendes rein:
edns-packet-max=1280
Danach führst du ein pihole restartdns aus.
Damit wird Pi-hole die Paketgröße auf max 1280 Byte festlegen und die Warnung sollte nicht mehr auftreten.
Danke habe ich gemacht.
Was hat das denn für Auswirkungen? Ich würde es gerne verstehen, warum diese Meldung überhaupt kommt. Hat es Nachteile, dass die Größe nun reduziert wurde oder Vorteile (mal abgesehen von der Meldung)?
Sollte ich noch die Größe in der unbound Konfig ändern?
# Reduce EDNS reassembly buffer size.
# Suggested by the unbound man page to reduce fragmentation reassembly problems
edns-buffer-size: 1472
Die Ursache ist folgendes: DNS queries werden normalerweise als UDP Pakete verschickt. Wenn diese zu groß sind, werden sie auf dem Weg vom Sender zum Empfänger an irgendeiner Stelle nicht mehr weitergeleitet bzw. beantwortet. Da UDP nicht verbindungsorientiert ist, erhält der Absender darüber keine Nachricht, sonder merkt nach einer gewissen Zeit, dass keine Antwort kam. Dann verringert er die Größe und sendet die Pakete nochmal. Darüber informiert dich dnsmasq hier, eben dass für 127.0.0.1 die max Paketgröße auf 1280 festgelegt wurde.
Prinzipiell haben größere Pakete den Vorteil, dass mehr Infos auf einmal gesendet werden können. Wenn diese dann ihr Ziel nicht erreichen und der Client wartet bis die Anfrage in den time-out läuft, dann ist das eine sehr viel langwierigere Sache, als wenn der Client gleich mehrere kleine Pakete senden würde.
Ja, kannst du machen, wir haben unsere Doku auch angepasst:
edns-buffer-size: 1232
https://docs.pi-hole.net/guides/dns/unbound/#configure-unbound
Ergänzend zu yubiusers Erläuterungen:
Vorteile: Wenn die maximal akzeptierte UDP-Paketgröße eines Upstream-DNS-Servers bekannt ist, kann ein Client direkt auf das dann notwendige TCP wechseln, ohne vorher auf eine letztlich ausbleibende UDP-Antwort zu warten, wodurch sich insgesamt die Zeitspanne bis zum Vorliegen der DNS-Antwort entsprechend reduziert.
Ich habe in der unbound Konfig nun auch edns-buffer-size: 1232 eingetragen und 99-edns.conf wieder gelöscht.
Aber auch damit kommt die Fehlermeldung mit der Reduzierung auf 1280.
Wie kann das sein, wenn das in der unbound Konfig niedriger eingestellt ist?
Wegen
Pi-hole versucht es zunächst also wieder mit 4096. Das klappt nicht. Dann versucht es erneut mit 1280. Das klappt (vermutlich) auch nicht. Bei weiteren Versuchen mit noch kleineren Größen wird nichts mehr geloggt.