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?
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
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 
*I couldnt find a wiki, hope the link is ok?
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.