"Maximum number of concurrent DNS queries reached" und "reducing DNS packet size" Meldungen

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 :slight_smile:

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.

1 Like

@yubiuser

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

3 Likes

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.

1 Like

@yubiuser

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.

Jetzt wird es ja ganz verwirrend. Wozu gibt es denn dann den Eintrag edns-buffer-size: 1232 in der unbound Konfigdatei?

Habe ich einen Gedankenfehler?

Wenn z.B. ein Client unbound direkt anfragt und dieser dann die Anfrage ohne den Pi-hole weiterleitet.

Question, the bit I dont understand, why does pihole-FTL needs to be configured with edns-packet-max=1232 while MTU size for the lo interface is ridiculously high 65536:

pi@ph5b:~ $ ip link show lo
1: lo: ... mtu 65536

Compared to 1500 for the eth0 interface used by unbound to query upstream:

pi@ph5b:~ $ ip link show eth0
2: eth0: ... mtu 1500

I would have expected unbound instead of pihole-FTL to be needing configuring to use 1232 bytes for upstream?

@yubiuser

Bedeutet das dann, dass pihole bei unbound intern größere Pakete, wie z.B. 4096 nutzt?

Die Root/TLD Server aber nur max. 1232 unterstützen und es dann zu dieser Meldung kommt mit der Anpassung an 1280?

@deHakkelaar Things have started to get mixed here. In the setup

Clients ---(1232 bytes for eth0)---> Pi-hole
Pi-hole ---(4096 bytes for lo)--->  unbound
unbound ---(1232 bytes for eth0)---> the Internet

you could use values as suggested above. However, neither Pi-hole nor unbound (actually, no DNS server I'm aware of at all) have any settings that allow different values for in- and outbound packets. This also doesn't make much sense. If one of the client retries over TCP, the entire chain has to be TCP upstream, too, according to the RFC. The unbound guide says: Both FTL and unbound should use the same setting when using unbound.

@THG Ja. Die saubere Lösung ist überall 1232 zu nutzen. Dann werden zu große Pakete sofort über TCP probiert und es kommt zu keinem ominösen Verlust bei gerade-etwas-zu-großen Paketen über UDP (die dann nach einem Timeout eh wiederholt werden würden). Die Dokumentation wurde entsprechend angepasst (siehe Link oben).

1 Like

@DL6ER

Ok verstehe. Das bedeutet dann aber auch, das bei unbound immer auch der nachfolgende Eintrag für pihole benötigt wird, allerdings mit 1232 und nicht mit 1280? Ist das so jetzt final richtig?

Ja. Der Wert 1280 ist genau so gut, die aktuelle Empfehlung liegt aber bei 1232. Da streiten sich wirklich die Experten um den optimalen Wert. Ich denke es gibt keinen. Alles kleiner-gleich 1280 ist völlig okay.

1 Like

Thx!
I suspected something like this but wasnt sure.

EDIT: Ow FYI, Signiant software can use different MTU for file transfer acceleration through UDP packets for different destinations by forking a new process I believe :wink:

*I couldnt find a wiki, hope the link is ok?