No warnings
I get a lot of warnings since the new update rolled out with the new ! at the top of the UI.
Most of them are: reducing DNS packet size for nameserver 9.9.9.9 to 1280
and some of them are about IPv6 that I saw someone else just post about, so I joined his post regarding those.
Running on a Raspberry Pi 4, with the latest everything.
pT3n6Pf1
OK, so the devs wanted these, so I'm reporting it. Just got the second post, it says it should do it only once and make that size permanent, that's not the case here, it does that a lot.
Always for the same server and with the same upper limit? If so, you have unveiled a probably long-standing dnsmasq bug.
Well, it depends on what you define as a session. If the session is 2 hours, then every 2 hours each server is issuing this warning. If that's normal operations, would it be possible to have a way to ignore these warning and have them not show up on the dashboard?
Also, if someone could look into the IPv6 errors I'm getting, posted in another thread by someone else as well, that would clear up all my warnings.
There is no documentation for dnsmasq warnings, hence, I wrote descriptions for every possible warnings I found in the source code. The documentation can clearly be improved as we see these warnings in the wild. A session is one minute by default, so what you are seeing doesn't look like a bug.
Actually, it is quite interesting that you see this only once per two hours (or whatever, but notably less than every minute). I tested quite a few servers and haven't seen such warnings a single time. The lack of reports on our support platforms suggests it is something special to your network.
What router and internet access do you use? Could you imagine anything that would cause this to happen?
Hypothesis: Your ISP is may be manipulating certain queries your Pi-hole is doing only once every two hours (TTL of 7200 seconds). Somehow this manipulation makes the DNS packets too big leading to truncation, triggering this warning.
You can get rid of the warning by adding a config file like /etc/dnsmasq.d/99-edns.conf and adding
edns-packet-max=1280
in there. Then run pihole restartdns and your Pi-hole will not even try with larger packet sizes (our default is 4096).
Great reply, thanks for explaining it. But the 2 hours make some sense, because if I remember correctly from my other bug posts, 2 hours is roughly the TTL of the DNS cache on these systems, no?
And one last question, is me lowering it going to affect anything performance wise?
I don't think so. Some very large DNS replies will not fit into a single packet any more, however, this is likely already not working right now for you triggering exactly this warning. Truncated queries will be retried over TCP.
OK, did that, will check later to see if it's solved.
updated my pihole without issues yesterday and had no issues until 2mins ago.., just seen this warning pop up (never seen it before)... doesn't seem to be causing any impacts, sites loading OK etc.
I deleted the warnings, reloaded the same site again and it didnt happene again
Yeah, these warnings have always been there, we just made them a lot more visible now. Before, you had to dig them out between a lot of other stuff in /var/log/pihole.log where they can easily get lost.
thanks!
It has been a few hours, no more warnings. thanks!
Just a quick reply. Thanks for the fix. I will say that I'm running 2 recursive BIND servers on my network. One is BIND 9.16 running on FreeBSD 13.0. The other is BIND 9.11 on Rocky Linux 8.5. Only BIND 9.11 is giving this error. Don't know if that makes a difference in your hypothesis. My ISP isn't messing around with the queries. My Router is pfSense 2.5.2.
The DNSMASQ error comes up immediately after restarting the Pihole process. It started this morning when I did my weekly udpates. The config file fix did stop the warnings though.
Thanks!
Yes, this makes me believe it is an bind issue. Either due to a misconfiguration (I guess you already ruled that out, though) or due to a bad default value for something you don't have configured at all. This would also make sense as you say that the latter bind version doesn't show this - the default value might have been adjusted as they realized this. Maybe the ISP's DNS servers are running the same "bad" bind version resulting in this seen by the other users.
I updated recently and looks like I am seeing something similar. Not sure exactly what this means though.
Version:
Docker Tag 2021.12
Pi-hole [v5.7]
FTL [v5.12]
Web Interface [v5.9]
Image of the warnings I am seeing.
I run a pfsense router which is the IP I have masked out, if that info is helpful at all.
@LIGISTX as I said above, this comes either from a misconfiguration of a component in your network (most likely the DNS server, but it can also be a router) or a bad default. See DNSMASQ_WARN reducing DNS packet size - #9 by DL6ER for a the solution. Note that setting a lower maximum packet size is not a workaround but a proper solution in this case.
Not sure about this statement:
setting a lower maximum packet size is not a workaround but a proper solution in this case
Others have stated that it has an inpact on performance: https://www.linksysinfo.org/index.php?threads/reducing-dns-packet-size-for-nameserver-127-0-0-1-to-1280.75502/
it seems to have an impact on the webpages loading response time
As far as I understand, a bigger buffer than 1280 is needed sometimes to avoid truncation, which can lead to retry on tcp and fragmentation.
I am only a user, so please correct me if my conclusion is wrong.
I said in this case because it seems that larger packets cannot make it anyway to their target and have to be retired with smaller packets even over UDP. The performance is much worse as the second UDP attempt is only made when we never receive a reply from upstream due to a packet that never reached its target (due to size). In contrast to TCP, we don't get status information about UDP transmissions and cannot know if a packet reached its target at all.
Hence, when you see this warning, it means that you have hit at least one timeout on UDP already. If the packet has to be retransmitted over TCP, that's an altogether different question and comes even thereafter.
TL;DR: The situation is worse with too large packets. Reduces packet size will make everything faster due to not having to retry after a timeout.
