"Number of bytes size to advertise as the EDNS reassembly buffer size. This is the value put into datagrams over UDP towards peers. The actual buffer size is determined by msg-buffer-size (both for TCP and UDP). Do not set higher than that value. Default is 1232 which is the DNS Flag Day 2020 recommendation. Setting to 512 bypasses even the most stringent path MTU problems, but is seen as extreme, since the amount of TCP fallback generated is excessive (probably also for this resolver, consider tuning the outgoing tcp number)."
Not necessarily. Something along the path from your Pi-hole to the final name server serving any domain you browse to. Pi-hole cannot find out which name server is responsible for the truncation. It doesn't have to be the first one on this path.
The limit is never surpassed for the vast majority of queries. Only those that trigger the warning are affected at all.
I'm not sure about this. There is something that affects your performance and you can fix it by appropriate configuration. Sounds logical to alert you that you should look at it. Once it is resolved, the earnings will not appear any longer.
In this case you should either use this value for the FTL setting or change both as advised by @jfb. This value is even lower than the 1280 I suggested above. We should update the documentation accordingly.
May I ask you?
How does the default setting, 4096, help?
I'm now scouring the threads on how to lower it to 1280...
I mean, sure, I know enough Linux pull up terminal or to to pull the card out, navigate to that directory, and add *.conf but there must be an easier way or, at least a justification, why the packet size, by default, is so large to begin with?
In all earnest: you guys have been all over the place squashing this alert; why not just lower it by default?
It is beneficial to handle large DNS replies over UDP without having to fall back to TCP. Retries can easily add unnecessary delays of up to several hundreds of milliseconds. The value of 4096 hasn't been invented by us but is suggested by the ENDS Internet standard, to be precise, RFC 6891 Section 6.2.5:
6.2.5. Payload Size Selection
Due to transaction overhead, it is not recommended to advertise an architectural limit as a maximum UDP payload size. Even on system stacks capable of reassembling 64 KB datagrams, memory usage at low levels in the system will be a concern. A good compromise may be the use of an EDNS maximum payload size of 4096 octets as a starting point.
A requestor MAY choose to implement a fallback to smaller advertised sizes to work around firewall or other network limitations. A requestor SHOULD choose to use a fallback mechanism that begins with a large size, such as 4096. If that fails, a fallback around the range of 1280-1410 bytes SHOULD be tried, as it has a reasonable chance to fit within a single Ethernet frame. Failing that, a requestor MAY choose a 512-byte packet, which with large answers may cause a TCP retry.
Values of less than 512 bytes MUST be treated as equal to 512 bytes.
Emphasis on the second paragraph. This is exactly what Pi-hole does. We implement the optional fallback ("MAY") and first try with a packet size of 4096 ("SHOULD"). We then drop to a value of 1280 ("SHOULD") if that doesn't work. We do not try a third time with 512 bytes ("MAY") and immediately retry over TCP as a network that cannot even handle 1280 bytes properly in one packet is considered severely broken and other things are expected to fail, too.
It is exactly here:
But it also was in the thread you posted your reply in, first.
Because this is not a good solution for everyone. I recommended reducing the payload size only for this who discovered that a larger payload size does not work for them. Many can handle larger DNS buffers just fine. For instance, my local unbound handles 4096 bytes packets just fine.
Because this doesn't seem to be documented anywhere properly, I probed all the DNS servers currently offered by Pi-hole to find out their maximum DNS packet size:
Maximum packet size
Quad9 (filtered, DNSSEC)
Quad9 (unfiltered, no DNSSEC)
Quad9 (filtered + ECS)
You see that several do allow for a packet size of 4096. Level3 even allows for insane 8192 bytes.
Thanks for the explaining.
I got it also with cloudflared using 22.214.171.124 as dns followed the official documentation.
For me it comes up about 1 or 2 times a week, so it's more rare. Since all seems to work fine for me, it is only a bit irritating.
Doing some research about the warning I've found this posts...
If you can probe DNS asking for the maximum-packet-size, couldn't you use those values in pihole? I mean, assigning the default-packet-size value of 4096 to each DNS server that is configured in pihole. On first use query the actual packet-size from the server, update the internal value and use that value when communicating with that server. That way would work with user-driven/custom DNS servers, we don't need to limit all DNS servers because of one raising that warning and could get the best performance from each server. Dont know how often that value should be updated, may be once a week or month (in case the value has been increased on the server) or once when a DNS_MASQ warning occured with that server.
Of couse, that is easier said than implemented. But may be you could put something like that on the todo-list of this awesome project
Sure, but you cannot. My study above was slowly increasing DNS packets with random data to said servers, carefully investigating the reply to find the upper boundary of there they either set the TC (truncated) bit or stop responding altogether. This sent a lot of packets to each and every server. If I do this once and put up a table that's one thing. If thousands of Pi-holes out there do this automatically...
We have been contacted by Github in the past because Pi-holes were keeping their API notably busy. I don't want to repeat this story elsewhere.
Maybe I am misunderstanding this. My upstream DNS is set to Cloudflare in pihole, and to the pihole IP in my router (ASUS - LAN - DHCP Server). I'm seeing about 50 of those messages a day now ("reducing DNS packet size for nameserver 126.96.36.199 to 1280"). Based on the table Cloudflare supports max 1452 and default is set to 4096... would it be best to say that if using any DNS server that is 1452 or below, always edit and set edns-packet-max=1280?
@ptero Does your Pi-hole show individual clients in the Query Log or only your router? Also, this may still be true as your router may be truncating the responses because of a low MTU. I don't think its' possible to give a general recommendation for all types of networks. Setting it to 1232 (not 1280) will always work. This is the default dnsmasq will have as a lower bound in the next releae.