i have a Windows Domain Controller and a BIND DNS Server as DNS in my environment.
I want to use Pi-Hole for both of them as a Upstream DNS Server
User Client -> Windows DNS -> Pi-Hole -> Quad9
User Client -> BIND DNS -> Pi-Hole -> Quad9
Now in Query Log i see only the last hop of the DNS Query (Client column) but not the real origin (User Client IP)
Example:
Client (192.168.1.44) -> Windows DNS (192.168.1.5) -> Pi-Hole (192.168.150.5) -> Quad9
(There is a Firewall between the Networks for routing 192.168.1.0 <-> 192.168.150.0 and Any traffic is allowed (no NAT))
In Query Log i see the IP of the Windows DNS (192.168.1.5) not the Client IP (192.168.1.44) like expected.
If that is the case, you can enable the EDNS0 debug in pihole to be more verbose. It will tell you, if EDNS information is available within the DNS requests
add DEBUG_EDNS0=true to /etc/pihole/pihole-FTL.conf and restart pihole (pihole restartdns). It will log to /var/log/pihole-FTL.log
Yes, i read your linked thread. But i understand only the half of it. Many unorganized informations in many answers.
Like i said i'm not that deep in linux, dnsmaq and dnsdist (goggle can't help every time).
I couldn't find where i have to make the changes (Windows DNS or in pi-hole self).
Sorry if i bother you with my lack of knowledge. I only don't understand why it isn't working even when the feature is implemented (in dev) and it was working two days ago with another solution (which stoped working yesterday out of nowhere).
dnsdist isn't relevant for you, it's just Pi-hole's embedded dnsmasq instance, pihole-FTL, that is adopting that ECS feature.
No need to apologize at all, we're all here to learn and share.
But as you've switched to a development branch now, you're kind of expected to be willing to experiment and to accept possible failures. You should also be aware that there's no guarantee in general whether a feature you are testing in development will make it into the next release in exactly the same way you are using it, though this specific ECS feature is very likely to make it. Final word on this is with the development team, though.
As for addressing your current issue, I think yubiuser is actively using that ECS feature, so he's in a far better position than me to steer you towards a working configuration.
Yes, i know. When i have a working setup in Dev Branch i will switch back to normal branch (but with more expertise). Its now the switch from PFsense to pi-hole and i need a working setup (with client recognition) for creating whitelists, blacklists, groups and so on.
In worst case i can bypass everything so its not that critical when pi-hole isn't working (because of Dev branch). (And i have a good backup so i can experiment )
Compare to what I see using dnsmasq with add-mac and add-subnet option
Your server is using ENS0, but sending a DNS cookie which does not contain the mac of the client. I'm not sure, if DNS cookies can be used to send client identifier (IP/Mac) or if Pihole capable of dealing with DNS cookies at all. Pinging @DL6ER
Add : if I understand correctly, you need the subscriber version of bind to use the ECS feature
We read them but we do not use them (because there is nothing useful in them for the statistics).
This is the issue. I don't see how
could have worked, if you changed no settings at all on the Windows ans BIND DNS servers.
There is also the proxy protocol which could contain this information. As this is something that is completely different from the DNS standard, we do not support this at the moment. It wouldn't be easily doable with the embedded dnsmasq resolver. However, an operating system DNS server with a few dozens of fixed (employed) code contributors may have support for this protocol. However, it is only speculations if this is due to the proxy protocol.
Was PFblockerNG installed at some kind of firewall/router level before? Maybe to was simply able to detect the true origin by network inspection. At this point, this is just another theory as well, however, it could have worked the following way:
Each DNS requests contains a unique request ID. This ID stays from the client to the Windows/BIND DNS server. It may stay constant from the Windows/BIND DNS server upstream (which was the PFsenseNG). If this would be true, it could infer the original requestor by identifying the original DNS request ID. As the Pi-hole in not employed at a router level, this kind of knowledge is unfortunately not available as we are not able to inspect your entire network in such a deep way (which may also be seen as a good thing, privacy-wise).
No, i only replaced PFsense with pi-hole. The DNS Setup is still the same.
The PFsense was only a DNSBL Server. Routing is through my Sophos firewall (So the PFsense had not more insight as the Pi-Hole).
)