Sorry, I was hurt.
The truth is:
Home users will not notice this issue. It is microseconds of delay.
You can dig into your MTU or make the .cfg but Pi-hole automatically reduces the packet size and always has.
I, honestly, do not know what information they are getting from this 'error'. If you are savvy enough to fix this, you can. If you are using Pi-hole in an enterprise, you know. If you want you can Unbound.
The rest of of us are being troubled by something we need not fix. I get this, maybe once a day and I do not notice the delay. The most annoying part: trashing the alerts.
edit
and no:
the magic number is 1232. And I understand the confusion: the goal posts have moved in this very thread.
"I just tried it and can confirm (at least for 9.9.9.9) that they changed it to 1232. I have no idea why you got it also for the other two, while I see
1.1.1.3 -> 1452
1.0.0.3 -> 1452
9.9.9.9 -> 1232
Maybe you should just change the config to
edns-packet-max=1232"
Youbi I'm not hating but this is an insane situation.
Respect for doing the work to find the change.Why can I not PM you all?
Please kill this alert. It is a moving mess. This thread will never end.
Ah sorry, I was unclear. The magic number for dnscrypt-proxy irrespective of upstream providers is 1252. Makes sense that you might need to lower if the upstream provider restricts it even further.
Well, how would you know? They just revised it.
You had the right number, and I got uppity and said the DNS can change it on a whim, was red flagged, and that is what happened.
edit
and it does not, really matter. The delay is unnoticeable in a home network,
That did work - but it does not anymore.
All of them complaining
Warning in dnsmasq core:
reducing DNS packet size for nameserver xxx.xxx.xxx.xxx to 1232
I have a /etc/dnsmasq.d/99-edns.conf since December 25th containing
edns-packet-max=1280
So what do you recommend?
I'm going to try 1232 as sweet spot as mentioned in earlier posts.
You will need to change your parameter from 1280 to 1232.
The change from 1280 to 1232 as safe low limit has been a recent one in dnsmasq. We inherited it with the most recent FTL release.
How do I add this when using the pihole docker container? I can't see an env var that allows me to set it.
you add it in the etc-dnsmasq.d folder in your container, in a new file you call for instance 99-edns.conf
I have something odd happening: recently, I started running Pi-Hole in combination with Cloudflared (pointing to Quad9 addresses) in containers (because it is now running on a Firewalla Purple device, but that is irrelevant).
Changing the max packet size to 1232 causes some addresses not to be resolved as the reply is BOGUS DNS KEY MISSING. Reverting the packet size limitation solves the problem...
(I sincerely dislike running Pi-hole in a container, and I dislike not being able to run Unbound for now as I'm not sufficiently knowledgeable about Docker - hopefully that will change soon)
Why are you changing the max packet size when cloudflared is the upstream set in Pi-hole?
Edit: That reply sounds harsh, not meant to be. If Pi-hole is talking directly to cloudflared then there is no need to reduce the packet size. If you are using DoH over cloudflared then even more reason to not need packet size modifications.
1 Like
Because I assumed that the reduction to 1232 was generally valid - seems I was wrong.
FYI: Regardless, I do get the warnings in Pi-Hole about the reduction multiple times per day.
Can you post a new debug log for me?
1 Like
Can't seem to upload to tricorder, so will send you in private message (and will include docker yaml)
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.
The next version of FTL (no ETA but then including dnsmasq v2.90) will change the default value of edns-packet-max to 1232. You can leave the option you already added manually in place, it won't harm.
3 Likes