I have dnsdist setup between Pi-hole and my clients. I use ECS Client Subnet as described in this topic to still have Pi-hole display the clients accurately.
Recently I've decided to change from using Cloudflare's DNS to Google's. I was surprised once making this change to find all of my queries were being rejected. Upon investigation I discovered that Pi-hole was sending the ECS subnet information from dnsdist to Google's DNS server. This post makes me think that this is not intended behavior. Google's DNS server is rejecting the queries with the following error: Provided ECS includes 32 bits, but no more than 24 are allowed. https://developers.google.com/speed/public-dns/docs/ecs.
I have tried to remove the ECS information from Pi-hole's forwarded requests by adding add-subnet=0,0 to the dnsmasq config, however that does not help. For my use-case, the subnet information should only be sent from dnsdist to Pi-hole.
What amount of DNS traffic do you have to cope with that you are load balancing DNS requests? Which other DNS servers besides Pi-hole is your dnsdist DNS load balancer using?
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
I think there is a misunderstanding regarding the post
EDNS(0) data is only sent if explicitly enabled in Pi-hole. EDNS(0) data is always analyzed when received .
My understanding is: Pi-hole only sends EDNS data when explicitly asked (by dnsmasq configuration) on queries that do not have EDNS data so far. But it will not strip existing EDNS data. But lets ask the one who wrote the code (@DL6ER)
The CentOS container I have Pi-hole on also has PowerDNS to handle authoritative resolution for my domains. This handles both internal queries from my LAN and external queries from the internet. dnsdist sorts between internal authoritative queries, internal recursive queries, and external authoritative queries. I recognize there are other ways of accomplishing this.
I see no gain sending it upstream, so I think it could be stripped by default. If the upstream is an internal server and if it is needed there one should still be able to switch stripping off.
I prepared a patch to be sent upstream to the dnsmasq project. We can try this here before sending it upstream as Simon Kelley is current busy and has no time to review new submissions anyway. Even when I agree with that it would be meaningful to be the default, I don't think Simon would see it the same way (it is breaking existing behavior). A new option Pi-hole includes by default seems to be the happy medium.
Unfortunately when I run pihole checkout ftl tweak/strip_EDNS0_ECS it returns pihole checkout ftl tweak/strip_EDNS0_ECS. Looking into it, it looks like a test is failing.
Ah, yes. The failing test prevents the upload of the binary as the CI assumes the generated FTL binary is broken. It seems verteiltesysteme.net is not available right now. Their entire infrastructure (134.91.78.139, 134.91.78.141, 2001:638:501:8efc::139, 2001:638:501:8efc::141) seems to be down.
This has already been discussed in the German part of this forum and is one of the top Google results for said domain today:
Got it, I guess it's a waiting game then. But still, thank you. It's amazing that in 6 hours of my initial post there is already a test patch made, I'm going to go donate!
The CI build workflow was updated recently and this is definitely a change in behavior. For now, I removed the tests from the workflow. This is harmless as we do not plan to merge this branch (instead, we will only distill a single feature patch out of it). Expect to see the testing branch binaries in a few moments.
which does the same EDNS(0) bits stripping for possibly embedded MAC data to ensure no private information is leaked if add-mac is used on some client.
Furthermore, I refined how the options strip-subnet and strip-mac work: You can now specify them together with the corresponding add-... options to achieve a replacement of the data. Note that this isn't currently possible in dnsmasq as add-subnet and add-mac only did something when no such information was present in the incoming query.
