DNS Service/FTL/Lost connection to API

Help Community Help
1

The issue I am facing:
Web interface says that my DNS Service is not running, nor is FTL. Going to the Pi-hole diagnosis, I get the message
2021-03-24 20:53:34 DNSMASQ_CONFIG FTL failed to start due to failed to create listening socket for port 53: Address already in use

I'm a Windows server admin who is much better at DNS/Networking than your normal windows ad, but am not an expert on linux.

I had this working last night (dig @127.0.0.1 google.com +short, worked as did dig @127.1.1.1 google.com +short, now only 127.1.1.1 works) Today it's failing. (I know those dig commands do not have an "at" symbol, but i'm being told I can't mention other users, and thinking maybe the "at" symbol was causing that)

Details about my system:
Ubuntu (20.04 guest) running pihole and stubby for DoT. I installed pihole first, gave it all the defaults, and then installed stubby for DoT. Stubby is running on 127.1.1.1:53 - so it should not be taking over either 127.0.0.1:53 or 192.168.1.217:53 which is the statically assigned IP I gave the server during build.
Netstat -nltup shows that nothing is running on either localhost or the 192. address on port 53

(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)

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      -
tcp        0      0 127.1.1.1:53            0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp6       0      0 :::80                   :::*                    LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      -
udp        0      0 127.1.1.1:53            0.0.0.0:*                           -
udp        0      0 0.0.0.0:68              0.0.0.0:*                           -

All those ports look good - lighttpd, stubby, sshd, and dhcpd (i do not use the dhcp server on pihole)

What I have changed since installing Pi-hole:

I've added stubby, which I had working. I pointed the upstream DNS server in pihole to point to 127.1.1.1 to use stubby.

I added several blacklists to Gravity, along with some common whitelist targets. That all worked.

I followed several of the top faq's including trying to attach the debugger ... but since pihole-FTL isn't running, I'm unable to find the PID to attach.

Thanks!

2

You can avoid that as well as auto-link creation by using the </> - Preformatted text option from the menu. I've just edited your post accordingly. :wink:

It shows port 53 TCP and UPD are bound by a process, but you didn't have sufficient privileges to list them.

Running sudo netstat -tulpn should reveal which process is hogging those ports and causing Pi-hole to fail trying to bind them.
It may be stubby if that hasn't been configured for a different port yet, or any other DNS server.

3

Bucking_Horn, Thanks for the edit - I'll remember that!

Onto the problem part, with screenshots this time...

You're absolutely right that stubby, as I mentioned above, is using port 53 on 127.1.1.1 What it's not doing is using port 53 on the ip configured on eth0 (192.168.1.217)Which is what pi-hole is configured to use.

image
image489×611 19.5 KB

I've stopped stubby, tried starting pihole again, and it failed to start (and I forgot to sudo, so I reran with it).

Untitled
Untitled1152×720 36.3 KB

Thanks again!

Danny

4

Pi-hole's embedded DNS server pihole-FTL, a tailored version of dnsmasq, by default will bind to interfaces rather than IPs.
In the default configuration, it will bind the lo as well as eth0 or wlan0.

As indicated, moving stubby to a different port should fix your port conflicts.
Don't forget to adjust Pi-hole's upstream accordingly, e.g. 127.1.1.1#5311.

EDIT: Should your issue still persist after that change, please upload a debug log and post just the token that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

5

I do have the option set to only use eth0, so I don't understand why pihole-FTL is grabbing everything.

I will also note that I rebuilt the server, re-installed pi-hole and stubby in the original configuration and it worked just fine - until a reboot (after which I just changed the stubby port and it's fine). Which makes me think there's an order loading issue (going beyond the original issue here, and now I'm just trying to learn), that would be fixed by controlling the order in which pihole-FTL and stubby start order. I know how I'd do this on Windows, but do you have any hints for googling on ways to do this on Linux?

Thanks!

Danny

6

I'd recommend to stick with separate ports.
It allows clean separation of external vs. internal/on-device DNS traffic so you wouldn't have to inspect port 53 traffic closely to find out which process would be handling a packet when in doubt.

Startup order would depend on your OS and the init system it uses, as well as how stubby is started.
You may want to use sudo systemctl status <service.name> to locate the service unit file, e.g. that's /etc/init.d/pihole-FTL for pihole-FTL.service.

It'll be probably interesting enough as a learning experience to figure out how to tackle your issue that way, but I'd still recommed separate ports. :wink:

7

FTL 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 big advantage of working even when interfaces come and go and change address (this happens way more often then one would think).

The option

bind-interfaces

forces FTL to really bind only the interfaces it is listening on.
Set it in some file like /etc/dnsmasq.d/99-user.conf.

About the only time when this is useful is when running another nameserver on the same machine on the same port. Well, you are looking exactly for this but it is really seldom required (and rarely useful, see the comment about different ports) and given the advantages I described above, it is not the default.

If you're further experimenting here, aso note that FTL automatically adds the loopback interface to the list of interfaces to use when the interface option is used only for some interface. This may be another issue here. Try to circumvent this by setting

except-interface=lo

I haven't been able to try this myself now but wanted to give some ideas for you.

9

Thanks! I am totally not the normal home network user, in that I know EXACTLY what's on my network and what IP it has. I mostly use the DHCP pool as a convenient way to get the mac address to give it a registration :slight_smile: Plus, at work things are nearly as rigid in the server areas where I am responsible (I work at a 50,000 or so member University - so the wifi is necessarily much looser - and boy am I glad I don't have to deal with administering that, my desire for things to be orderly would make me go crazy there).
So yeah, interfaces coming, going, and changing IPs aren't things that happen to me. I'm sure that they do for most people, so your default makes total sense! I'm perfectly happy using an alternate port for stubby now that I understand WHY. Thanks for explaining!
Danny

10

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.