The ask: Add support within FTLDNS for parsing the IP address/subnet passed from another dnsmasq client via
add-subnet=32,128 and potentially
add-mac. Asking that FTLDNS support parsing of ECS (EDNS0 Client Subnet) data from an inbound query on the requesting side.
I have an OpenWrt router running dnsmasq for my three client subnets. It forwards queries to my Pi-hole server, which is running on a separate VM. Traditionally, the recommendation by many in the Pi-hole community is to have dnsmasq on OpenWrt just hand out the Pi-hole IP via DHCP (option 6). Technically, this works and I realize it fits the majority of use-cases.
My use-case is perhaps a little more unique. On my OpenWrt router, dnsmasq is updating local ipsets (using
--ipset) for QoS on my router. I cannot seem to come up with a workable option around this, so bypassing dnsmasq as my first-contact DNS on OpenWrt is not an option for me at this point.
I am trying to switch back to Pi-hole from NextDNS. My previous configuration was running the NextDNS client on my OpenWrt router, still having dnsmasq as the first-contact DNS, then forwarding to the NextDNS client on an alternate port number. As long as dnsmasq was configured with these options, the actual requesting client's IP (and MAC) were passed through dnsmasq to the NextDNS client:
This allowed every query in NextDNS' console to show the client IP/hostname (via local resolution). Ref: https://github.com/nextdns/nextdns/wiki/DNSMasq-Integration I believe this is currently handled by parsing the ECS (EDNS0 Client Subnet) data from the inbound DNS query (coming in to FTLDNS from dnsmasq, in this case).
My hope is that FTLDNS could be updated to check for the same data in an inbound query and indicate the actual client IP that sent the request as opposed to the IP address of the OpenWrt server for every query. I think this could simplify configuration for a lot of Pi-hole users, too, even if the use-case isn't as technically required as in my case.