is this an expected behavior? As mentioned in the title, pihole discards EDNS information emebdded in the dns-query when the "client subnet" field doesnt contain the whole ip address. (/32)
Expected Behaviour:
Pihole forwards EDNS information to upstream resolver even when only the client network address (e.g. 94.112.65.0) is provided in the "client subnet" field. The client could benefit from edns without leaking the whole client ip.
Actual Behaviour:
EDNS information embedded in dns-query get discarded. pihole-FTL logs the following message:
Found malicious EDNS payload, skipping record.
Please provide more details about your configuration. Which config lines did you use to configure this? How did you find out it is discarded (I guess you did some packet inspection)? We need these information to know where we should be looking at together.
Can you quote the exact lines? I'd also be interesting to see what FTL tries to parse here. Please add
DEBUG_EDNS0=true
to the file /etc/pihole/pihole-FTL.conf (create if it does not exist) and run
Iam using dnsmasq as resolver in my local network and pihole as upstream resolver on a VPS.
Ive tested the following two configurations to activate ECS/EDNS0 Client Subnet.
add-subnet=MY_IP_ADDRESS/32 <- works as expected, pihole-FTL.log doesn't show any error and the complete client ip gets forwarded to the upstream resolver definded in pihole.
add-subnet=MY_IP_ADDRESS/24 <- Doesn't work, pihole-FTL.log shows the following error, client-ip is not visible on upstream resolver defined in pihole:
Thanks for the debug data, I'll check this in s few hours when I'm back from work
Sorry, it's still somewhat unclear to me what you want to achieve, you'll only be able to benefit from EDNS when providing a public IP address to the resolver (so it can give you the best CDN nodes, for example).
Okay, I tried this now and found two things: (1) FTL incorrectly logs an error because it expected a 32 bit address, however, (2) it still forwards the ECS data correctly.
I repeated my test with a packet dump to confirm this. Let me describe how I tried to reproduce it so you can compare this to your setup:
A client calls dig google.com @127.0.0.0 -p 5355
127.0.0.1:5355 is a dnsmasq instance is listening with the configuration
server=127.0.0.1#53
add-subnet=1.2.3.0/24
127.0.0.1:53 is my Pi-hole in turn asking 127.0.0.1:5353 as upstream resolver
127.0.0.1:5353 is a local unbound instance
This tries to replicate your setup albeit everything locally (which shouldn't matter).
I did another pcap to check if the ECS data gets processed correctly. (why didn't I do it directly ) The requests getting processed by dnsmasq and forwarded to my upstream resolver, even when I set my network address (.0/24) as edns-client-subnet. That seems to work as expected.
) The requests getting processed by dnsmasq and forwarded to my upstream resolver, even when I set my network address (.0/24) as edns-client-subnet. That seems to work as expected.