The issue I am facing:
I am currently running two new instances of Pihole, their traffic is forwarded (Primary and Secondary DNS) from another DNSMASQ (same DNSMasq instance) instance with the given options --add-mac, --add-subnet to handle identification of the clients on the adjacent network. Is it the expected dnsmasq behavior for only one pihole to receive client information, while the other doesn't. Is there a way to troubleshoot the second pihole instance not receiving client information like the primary one is.
Details about my system:
Raspberry Pi 4 times 2 What I have changed since installing Pi-hole:
Nothing, New setup.
Okay so after running the Debug log for EDNS0, it looks like it is properly identifying devices. Pihole statistics is not properly reflecting it though. Is there away to repair this issue?
To help us to help you, please adhere to our template: Describe your expected behaviour and your diverging observation. It would also help if you could provide some actual examples, and a debug token.
Please include the logs here as well. It's okay to replace MAC and IP addresses (partially) for privacy reasons when they are still distinct afterwards.
The log behavior actually looks completely normal compare to the Working Pihole's log. I am seeing the same entries with no error messages. I am going to run the diagnostic.
which looks to me like the information is getting sent. My other Pihole looks like it is getting similar debug logs. The Pihole in question is not taking the information provided by the EDNS and applying into the statistics charts like my other pihole is.
I did a pihole debug log which failed to find any actual issues.
In my statistics, all i am seeing is IP addresses.
Here is a Debug token: https://tricorder.pi-hole.net/MeaPpjI1/
Current Behavior: Pihole is detecting EDNS0 information, but is not populating it to network tables or statistic information.
Expected Behavior: Pihole should populate Hostnames for IP address from EDNS0 information connected.
Current Steps taken:
Made sure DNSMasq of requesting server had the proper EDNS options turned on such as add-mac and subnet option.
Your above log lines suggest that EDNS(0) options are received successfully.
An RFC7871 extended client subnet option includes client address information in DNS messages, i.e. a receiving DNS resolver will be able to see that address information of the original requesting client (e.g. an IPv4 address), even if it is behind a router.
To associate such an IP address with a hostname, you'd have to provide the respective DNS records, either by defining them locally (e.g. via Pi-hole's Local DNS Records) or by configuring Conditional Forwarding.
The latter would be the more convenient way, but your current debug log shows you are not using CF?
These request are being done locally, in a network setup which the pihole resides locally. The purpose of looking to the EDNS0 information is strictly to gather the client information for statistic purposes. Pihole has been told not to forward this information upstream. Conditional Forwarding would create unecessary work when the whole point is for pihole to get that information from the EDNS0 information being sent to it from a local DNSMASQ instance that is forwarding request to it. I have one pihole that is already successfully doing this, but the other Pihole is not producing the same results.
As mentioned above, EDNS(0) ECS just includes address information. It doesn't carry any names of requesting hosts.
If your other Pi-hole instance is able to resolve IP addresses into hostnames, it has to source them from somewhere. Look for differences in that Pi-hole's and its host machines configuration, like Pi-hole's DHCP lease information (if acting as DHCP server), local DNS record definitons, CF, or a local resolver somewhere in its upstream DNS resolution chain that may return hostnames for Pi-hole's regular PTR requests.
You may also share a debug token for your other Pi-hole instance for us to have a look.
I solved the issue by setting up Conditional forwarding per you suggestion. I also setup local ptr records on the forwarding dnsmasq instance to prevent a DNS loop.
