as pihole does not provide dns privacy using DNS-over-TLS (DoT), I used older versions of pi-hole together with the dns proxy stubby (DoT). After switching to pihole-FTL, this doesnt seem to work anymore. I checked two different pihole installations, and both complain "failed to create listening socket for port 53 : Address already in use". After stopping and disabling stubby using systemctl, pihole-FTL works again as expected.
Is there anything I can do about this?
best regards, and thank you for this nice peace of software
In Pi-Hole V4.0 and later, dnsmasq is embedded in pihole-FTL, and dnsmasq no longer runs as a separate process. The debug log will show dnsmasq as either failed or inactive. Process pihole-FTL should be shown running on port 53.
Since dnsmasq is now embedded in pihole-FTL, existing dnsmasq configuration files will work as before, assuming they are compatible with dnsmasq V2.80. You should look on the stubby site for a guide which is more recent and works with Pi-Hole V4 and later.
You also have other options for encrypted DNS. There is a guide on the Pi-Hole documentation site for installing DNS over HTTPS with Cloudflared.
I did not change any configs of dnsmasq, nor did I change configs of pihole-FTL. And stubby has got his own loopback address and port (127.0.0.11), so in theory it should not interfere with dnsmasq/FTL, as FTL should only listen on 127.0.0.1. Still pihole-FTL complains, as long as stubby.service is enabled.
I just cross checked with cloudflared. Same problem:
sudo systemctl enable cloudflared
sudo reboot
sudo systemctl status pihole-FTL
[...] failed to create listening socket for port 53 : Address already in use
Meanwhile I found a workaround for my setup:
I slow down the start of stubby.service and cloudflared.service
by adding "Type=idle" to the corresponding unit files.
After doing so, and rebooting, pihole-FTL does not complain.
I then add stubby as the only upstream dns server to pihole,
and dns service works again as expected.
Do you consider addressing the underlying problem?
The workaround seems to work for my setup so far,
but to me, something seems wrong under the hoods.
How can a dns proxy stop pihole-FTL from working,
if they both use different loopback adresses for listening?
You started with an older version of Pi-Hole and likely an old version of Stubby. Without knowing all the details of your configuration, it is difficult to determine why the conflict exists.
I compiled stubby 0.25 from source. I installed cloudflares own binary.
Both proxys work seamlessly, if queried directly like this: dig @127.0.0.1 -p 5053 pi-hole.net)
I could start from scratch, if that would be of help.
I was curious and have rechecked the steps on a spare sd-card using current raspbian (stretch):
installed current pi-hole 4.2.1: pi-hole dns service works
installed current stubby from source, listening address 127.0.02: stubby works, pi-hole dns service works
configured 127.0.0.2#53 as upstream dns server in pi-hole web ui: pi-hole dns service works
restarted raspberry pi: pi-hole dns service does not work |
added "Type=idle" to stubby.service: pi-hole dns does not work (although this helped on two other systems as metioned above)
home/pi# service pihole-FTL status -l **●** pihole-FTL.service - LSB: pihole-FTL daemon Loaded: loaded (/etc/init.d/pihole-FTL; generated; vendor preset: enabled) Active: **active (exited)** since Thu 2019-02-14 14:05:16 CET; 42s ago Docs: man:systemd-sysv-generator(8) Process: 355 ExecStart=/etc/init.d/pihole-FTL start (code=exited, status=0/SUCCESS) Feb 14 14:05:03 cube systemd[1]: Starting LSB: pihole-FTL daemon... Feb 14 14:05:03 cube pihole-FTL[355]: Not running Feb 14 14:05:15 cube su[1174]: Successful su for pihole by root Feb 14 14:05:15 cube su[1174]: + ??? root:pihole Feb 14 14:05:15 cube su[1174]: pam_unix(su:session): session opened for user pihole by (uid=0) Feb 14 14:05:16 cube pihole-FTL[355]: dnsmasq: failed to create listening socket for port 53: Address already in use Feb 14 14:05:16 cube systemd[1]: Started LSB: pihole-FTL daemon.
To me, there seems to be a bug in dnsmasq/pihole-FTL, when it comes to opening the listening port.
I'd love to help more. Drop me a line, if I can help with more data.
On one of the systems, cloudflared is installed (127.0.0.1:5053), but disabled using systemctl.
The third system I am talking about in my last posts does not contain cloudflared.
|