Listen only on interface eth0 setting do not work

[kolargol]

Versions

Pi-hole version is v5.5 (Latest: v5.5)
AdminLTE version is v5.7 (Latest: v5.7)
FTL version is v5.10.2 (Latest: v5.10.2)

Platform

• Platform: Debian 10.10

Expected behavior

Setting "Listen only on interface eth0" should listen on eth0 interface

Actual behavior / bug

DNS listen on all interfaces in the system

Steps to reproduce

Set "Listen only on interface eth0" in admin/settings (web interface), check on system:

netstat -plan | grep 53
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 13284/pihole-FTL
tcp6 0 0 :::53 :::* LISTEN 13284/pihole-FTL
udp 0 0 0.0.0.0:53 0.0.0.0:* 13284/pihole-FTL
udp6 0 0 :::53 :::* 13284/pihole-FTL

[Asleep-at-the-wheel]

Hello,

Pi-hole v5.6 FTL v5.11 Web Interface v5.8

I believe I am dealing with the same issue, I updated and rebooted my machine yesterday to only be met with:
2021-12-18 16:33:20 | DNSMASQ_CONFIG | FTL failed to start due to failed to create listening socket for port 53: Address already in use -- | -- | --

Which is true if you investigate:
[x@y z]# ss -tulpna | grep 53
udp UNCONN 0 0 192.168.122.1:53 0.0.0.0: users:(("dnsmasq",pid=1768,fd=5))*
udp UNCONN 0 0 0.0.0.0:5353 0.0.0.0:* users:(("avahi-daemon",pid=908,fd=15))
udp UNCONN 0 0 [::]:5353 [::]:* users:(("avahi-daemon",pid=908,fd=16))
tcp LISTEN 0 32 192.168.122.1:53 0.0.0.0: users:(("dnsmasq",pid=1768,fd=6))*

However, those ports and addresses are virtbr0, not ens3:
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:c8:40:cf brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever

Further to here:
[x@y z]# ps -ef | grep dns
dnsmasq 1768 1 0 Dec17 ? 00:00:02 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
root 1772 1768 0 Dec17 ? 00:00:00 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper

When I have this box clearly ticked (and always have)

setupVars.conf shows:
PIHOLE_INTERFACE=ens3

So libvirt is running dnsmasq on bridge interface (correctly so) and FTL refuses to start because of it.... I have not experienced this in the past, so it must be a new(ish) issue.

Killing libvirt dnsmasq fixed it for now, but I don't consider that a solution.
[x@y z]# killall dnsmasq

Start DNS server via Pihole web interface and it looks to have stolen every interface.

[x@y z]# ss -tulpna | grep 53
udp UNCONN 0 0 0.0.0.0:53 0.0.0.0: users:(("pihole-FTL",pid=100207,fd=4))*
udp UNCONN 0 0 0.0.0.0:5353 0.0.0.0:* users:(("avahi-daemon",pid=908,fd=15))
udp UNCONN 0 0 [::]:53 [::]: users:(("pihole-FTL",pid=100207,fd=6))*
udp UNCONN 0 0 [::]:5353 [::]:* users:(("avahi-daemon",pid=908,fd=16))
tcp LISTEN 0 32 0.0.0.0:53 0.0.0.0: users:(("pihole-FTL",pid=100207,fd=5))*
tcp LISTEN 0 32 [::]:53 [::]:* users:(("pihole-FTL",pid=100207,fd=7))`

[x@y z]# cat /etc/redhat-release
CentOS Linux release 8.5.2111
[x@y z]# uname -a
Linux x.y.z 4.18.0-348.2.1.el8_5.x86_64 pi-hole/pi-hole#1 SMP Tue Nov 16 14:42:35 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
[x@y z]# rpm -qa | grep dnsma
dnsmasq-2.79-19.el8.x86_64

[DL6ER]

Two questions:

1. What does /etc/dnsmasq.d/01-pihole.conf say what interface Pi-hole should be listening on?
   Is there a single line interface=ens3 and no other lines like except-interface=... ?
2. What other files are in /etc/dnsmasq.d and how does /etc/dnsmasq.conf look like?

[Asleep-at-the-wheel]

1. What does /etc/dnsmasq.d/01-pihole.conf say what interface Pi-hole should be listening on?
   Is there a single line interface=ens3 and no other lines like except-interface=... ?

[x@y dnsmasq.d]# cat 01-pihole.conf shows only 'interface=ens3' of interest, everything else seems normal.

2. What other files are in /etc/dnsmasq.d and how does /etc/dnsmasq.conf look like?

Only other file is 06-rfc6761.conf
cat 06-rfc6761.conf | grep -v '#'
server=/test/
server=/localhost/
server=/invalid/
server=/bind/
server=/onion/

[x@y dnsmasq.d]# cat ../dnsmasq.conf
conf-dir=/etc/dnsmasq.d

[DL6ER]

Ah, sorry, I see this was a misunderstanding. Indeed, when setting to listen only on interface ens3, we still bind to the wildcard-address because the interface may come and go. Binding to addresses of a (not yet) existing interface does obviously not work.

What you want can be achieved when you add the config line

bind-interfaces

man dnsmasq also described why this option is helpful for what you want:

bind-interfaces
On systems which support it, dnsmasq binds the wildcard address, even when it is listening on only some interfaces. It then discards requests that it shouldn't reply to. This has the advantage of working even when interfaces come and go and change address.
This option forces dnsmasq to really bind only the interfaces it is listening on. About the only time when this is useful is when running another nameserver (or another instance of dnsmasq) on the same machine. Setting this option also enables multiple instances of dnsmasq which provide DHCP service to run in the same machine.

I think both views to the problem are justified, maybe we have to clarify on the web interface?

[Asleep-at-the-wheel]

Ok, this makes sense.

The web interface should probably refer to it as "respond from" rather than "listen" if that's the case.

It should also be made clear that PiHole is incompatible with libvirt too. Libvirt default is a virtual network adapter running NAT and dnsmasq as seen in my above post. If binding to * is not going to change then those two applications can't be run on the same machine.

[DL6ER]

Not being a native speaker, I'm always thankful for such suggestions. I will also add a reference to our documentation: https://docs.pi-hole.net/ftldns/interfaces/#technical-details

[kolargol]

Ok so this option should be renamed as it is nowhere close to "Listen on" which is "industry standard" meaning one thing and not anything else: process binds to specified interface and that's it.

Btw, I think it would be nice to have option to bind to specified interface despite possibility it will go off and on. In systems where there are multiple interfaces and services that would be helpful. Now it need to fiddle with listen ports on them which make everything more complex and confusing :)

[DL6ER]

I was thinking about something like this

[Asleep-at-the-wheel]

That is still confusing to me, because the option Bind only to interface enp2s0 makes it sound like the issue we had earlier.

If you are binding wild card then perhaps the term binding should be done away with all together, because it becomes more of an access list or filtering system rather than a binding system.

Options like:

• Allow from only local network
• Respond only on X
• Permit all

Make more sense to me, but that's because I am a networking simpleton and not a developer I guess. I am not a developer so I appreciate everything anyways.

[DL6ER]

That is still confusing to me, because the option Bind only to interface enp2s0 makes it sound like the issue we had earlier.

Yes, this is an altogether fourth, new option that implements exactly what were talking about here: interface=eth0 in combination with bind-interfaces.

The other options avoid the terms "bind" and "listen".

[Asleep-at-the-wheel]

Oh!

In that case it makes perfect sense!

Great work.

[yubiuser]

This should be fixed with
https://discourse.pi-hole.net/t/pi-hole-ftl-v5-12-web-v5-9-and-core-v5-7-released/51795/1