pihole-FTL failed to create listening socket for port 53


#1

Hi,

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 :slight_smile:


DNS service not running
#2

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.

https://docs.pi-hole.net/ftldns/dns-resolver/

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.

https://docs.pi-hole.net/guides/dns-over-https/


#3

Thank you for your fast answer :slight_smile:

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

If I do this:

sudo systemctl disable cloudflared
sudo systemctl stop pihole-FTL
sudo systemctl start pihole-FTL

pihole-FTL works as expected.


#4

What is the output of this command - something is on port 53 and preventing Pi-Hole from being on that port:

sudo netstat -nltup | grep 'Proto\|:53 \|:67 \|:80 \|:471'


#5

I added port 5053 (cloudflared)

netstat -nltup | grep 'Proto\|:53 \|:67 \|:80 \|:471 \|5053'

This is the output:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      719/lighttpd        
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      640/pihole-FTL      
tcp        0      0 127.0.0.1:5053          0.0.0.0:*               LISTEN      683/cloudflared     
tcp6       0      0 :::80                   :::*                    LISTEN      719/lighttpd        
tcp6       0      0 :::53                   :::*                    LISTEN      640/pihole-FTL      
udp        0      0 127.0.0.1:5053          0.0.0.0:*                           683/cloudflared     
udp        0      0 127.0.0.2:53            0.0.0.0:*                           685/stubby          
udp        0      0 0.0.0.0:53              0.0.0.0:*                           640/pihole-FTL      
udp        0      0 0.0.0.0:67              0.0.0.0:*                           640/pihole-FTL      
udp6       0      0 :::53                   :::*                                640/pihole-FTL

#6

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.


#7

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?


#8

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.


#9

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.


#10

I don’t think that’s required. Sounds like your problem is resolved.


#11

Hi again,

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 :expressionless: |
  • 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.


#12

Have you tried putting Stubby on a different port? This behavior is in dnsmasq, so if it is a bug, it is not a Pi-hole bug.


#13

I tried that now too, and gave stubby 127.0.0.2:10053.

After a reboot, pihole dns service does not work, the service just dies while starting:

service pihole-FTL status -l
● pihole-FTL.service - LSB: pihole-FTL daemon
Loaded: loaded (/etc/init.d/pihole-FTL; static; vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd-sysv-generator(8)

Then i run
pihole -r
And pihole dns service works as expected.


#14

Are you using Stubby or Cloudflared for your encrypted DNS (or both)? You noted that both were installed, but are you using both?


#15

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.


#16

What is the output of this command? journalctl -u pihole-FTL
There must be some reason it does not start.