But what if you could specify to Accept DNS Queries only from certain Subnets ?
AFAIK there is no custom DNSmasqd config line for this ?
The reason I am bringing this up is the following :
More and more people are using their Router for VLAN and VPN purposes with multiple subnets involved that can’t be all part of the Pi/NUC/Container/VM/Server that is running Pi-Hole for them.
We all know the option ‘Permit All Origins’ can take care of this, but since IPv6 is becoming more and more available for a lot of people we don’t want Pi-Hole to be active on a Public IPv6 Address and perhaps by mistake become available on the Internet for everyone!
It would be nice to specify all the subnets it should accept DNS queries from and simply ignore all others.
I know you could Firewall the device running Pi-Hole and everything, but this would add a great piece of userfriendlyness to Pi-Hole IMHO
This would only be a band-aid fix compared to a real solution like a firewall. The gateway router should have sensible defaults and not let WAN -> LAN inbound traffic reach devices as-is. With IPv4 this was automatically done via (an arguably worse solution) NAT.
I think we should not let users get away with not using a firewall.
This would pretend Pi-hole adds security only a firewall can provide, even though Pi-hole can’t.
I recently had the fun of getting a proper static IPv6 prefix and setting up routing and firewalling with nftables. One of the thing I had to learn while testing is that the router’s firewall should protect itself as well as LAN from inbound traffic originating in WAN.
OK, but now people freak out because of the fact that ‘Permit All Origins’ has that Firewall/Port Forward mentioning and have no alternative option…
Ofcourse we should not let them get away with not using a Firewall, but a bit more specific/updated “Which origins are allowed ?!” configuration wouldn’t be that bad at all after all this time IMHO
Yes, that wording has created some misunderstandings, I also experienced on here that some were quite reluctant to enable it due to the big warning label. The case I remembered is this.
The case you are describing sounds like a misconfigured router allowing all WAN -> LAN traffic. Your proposed new option would make it worse by pretending Pi-hole can fix it even though the issue is much more severe and can ONLY be solved by fixing the router’s firewall.
I am not qualified here, but I think this would require touching many internal dnsmasq parts. This would make it out of scope for Pi-hole and be better requested upstream at dnsmasq.
But that’s the thing : What if it’s needed for a subnet that Pi-Hole can’t have an Interface for like for example a VPN related subnet ?
Or a remote subnet so to speak ?
As mentioned by rdwebdesign, it is quite possible to use native dnsmasq options for customisation:
If you wouldn't be able to configure what you want to achieve with existing dnsmasq options, you'd probably need to file a feature request with dnsmasq.
NOFI but I have read the MAN page of DNSmasqd many times in the past and the last couple of days and NONE of those apply to this exact situation that I am describing ?!
To expand, dnsmasq deals with interfaces, it does not do any kind of filtering or listening for source IP addresses or net masks. You'd need to change dnsmasq to behave that way and my recollection from the dnsmasq mailing list is that the question was asked a few times before and Simon said no.
I'm not sure where your concern about IPv6 comes in but the default directives that FTL uses includes local-service (without-parameter):
--local-service[=net|host]
Without parameter or with net parameter, restricts service to connected network. Accept DNS queries only from hosts whose address is on a local subnet, ie a subnet for which an interface exists on the server. With host parameter, listens only on lo interface and accepts queries from localhost only. This option only has effect if there are no --interface, --except-interface, --listen-address or --auth-server options. It is intended to be set as a default on installation, to allow unconfigured installations to be useful but also safe from being used for DNS amplification attacks.
OK, but could you explain which commands/options are used to create ‘Permit All Origins’ then exactly ?
That’s the part I am mainly struggeling with :
How does FTLDNS a.k.a. “DNSmasqd on Steroids” suddenly know it should accept all origins of DNS queries while one or more of those are not connected to any of it’s Local Interfaces ?!
Somehow after all of these years of using Pi-Hole it seems I have never understood/figured this out completely I guess…
Every option for dns.listeningMode simply injects lines to /etc/pihole/dnsmasq.conf.
This seems to be explained on the docs page you linked in the original post Interfaces - Pi-hole documentation .
There is also the more hidden value NONE, which will add none of those lines to /etc/pihole/dnsmasq.conf.
LOCAL is the only option where the source address actually matters. For SINGLE and BIND, only the incoming interface matters.
The description shown in the config is slightly different than the one shown in the web interface. Maybe it helps Configuration - Pi-hole documentation
