DNS resolvers stops randomly

Expected Behaviour:

DNS resolving works all the time.

  • operating system: Ubuntu 20.04.1 LTS - 5.4.0-47-generic
  • hardware: old laptop with i5 M430 @ 2.27GHz

Actual Behaviour:

At random moments the DNS resolver stops working. Pihole is still running as the website works fine. However DNS is not resolved for any device. The website indicates that FTL is not running. Clicking "Restart DNS resolvers"on the website system settings or executing pihole restartdns resolves the issue.
This issue makes pihole practically unusable for me.

Debug Token:

Your debug token is: https://tricorder.pi-hole.net/p6o3dvhe6e

Logs

After 08:33:36 no more DNS requests are resolved (or even received?) until restarted at 07:22:19:

Sep 10 08:33:18 dnsmasq[452798]: interface veth449c9f4 failed to join DHCPv6 multicast group: Cannot allocate memory
Sep 10 08:33:18 dnsmasq[452798]: try increasing /proc/sys/net/core/optmem_max
Sep 10 08:33:18 dnsmasq[452798]: interface vethc0339cb failed to join DHCPv6 multicast group: Cannot allocate memory
Sep 10 08:33:18 dnsmasq-dhcp[452798]: no address range available for DHCP request via docker0
Sep 10 08:33:18 dnsmasq-dhcp[452798]: DHCP packet received on vethc0339cb which has no address
Sep 10 08:33:19 dnsmasq-dhcp[452798]: DHCP packet received on vethc0339cb which has no address
Sep 10 08:33:19 dnsmasq-dhcp[452798]: RTR-SOLICIT(docker0) 02:42:79:24:3c:97
Sep 10 08:33:22 dnsmasq[452798]: try increasing /proc/sys/net/core/optmem_max
Sep 10 08:33:22 dnsmasq[452798]: interface veth140b2cb failed to join DHCPv6 multicast group: Cannot allocate memory
Sep 10 08:33:22 dnsmasq[452798]: try increasing /proc/sys/net/core/optmem_max
Sep 10 08:33:22 dnsmasq[452798]: interface vethd611970 failed to join DHCPv6 multicast group: Cannot allocate memory
Sep 10 08:33:22 dnsmasq-dhcp[452798]: RTR-SOLICIT(docker0) 02:42:79:24:3c:97
Sep 10 08:33:22 dnsmasq-dhcp[452798]: DHCP packet received on vethd611970 which has no address
Sep 10 08:33:22 dnsmasq-dhcp[452798]: DHCP packet received on vethd611970 which has no address
Sep 10 08:33:23 dnsmasq-dhcp[452798]: no address range available for DHCP request via docker0
Sep 10 08:33:23 dnsmasq[452798]: listening on veth140b2cb(#6199): fe80::7088:ceff:fe2a:2b1e%veth140b2cb port 53
Sep 10 08:33:24 dnsmasq[452798]: query[AAAA] dns.msftncsi.com from 192.168.1.1
Sep 10 08:33:24 dnsmasq[452798]: cached dns.msftncsi.com is fd3e:4f5a:5b81::1
Sep 10 08:33:24 dnsmasq[452798]: query[A] dns.msftncsi.com from 192.168.1.1
Sep 10 08:33:24 dnsmasq[452798]: forwarded dns.msftncsi.com to 1.1.1.1
Sep 10 08:33:24 dnsmasq[452798]: validation result is INSECURE
Sep 10 08:33:24 dnsmasq[452798]: reply dns.msftncsi.com is 131.107.255.255
Sep 10 08:33:26 dnsmasq[452798]: query[A] acer-laptop.home from fd76:8995:4af8:1:7147:acd0:360b:d161
Sep 10 08:33:26 dnsmasq[452798]: config acer-laptop.home is 192.168.1.3
Sep 10 08:33:26 dnsmasq[452798]: query[AAAA] acer-laptop.home from fd76:8995:4af8:1:7147:acd0:360b:d161
Sep 10 08:33:26 dnsmasq[452798]: config acer-laptop.home is NODATA-IPv6
Sep 10 08:33:30 dnsmasq[452798]: try increasing /proc/sys/net/core/optmem_max
Sep 10 08:33:30 dnsmasq[452798]: interface vethbe8698b failed to join DHCPv6 multicast group: Cannot allocate memory
Sep 10 08:33:30 dnsmasq[452798]: try increasing /proc/sys/net/core/optmem_max
Sep 10 08:33:30 dnsmasq[452798]: interface veth2623ee7 failed to join DHCPv6 multicast group: Cannot allocate memory
Sep 10 08:33:30 dnsmasq-dhcp[452798]: DHCP packet received on veth2623ee7 which has no address
Sep 10 08:33:30 dnsmasq-dhcp[452798]: no address range available for DHCP request via docker0
Sep 10 08:33:31 dnsmasq-dhcp[452798]: DHCP packet received on veth2623ee7 which has no address
Sep 10 08:33:31 dnsmasq-dhcp[452798]: RTR-SOLICIT(docker0) 02:42:79:24:3c:97
Sep 10 08:33:34 dnsmasq[452798]: try increasing /proc/sys/net/core/optmem_max
Sep 10 08:33:34 dnsmasq[452798]: interface vethdf2b4b7 failed to join DHCPv6 multicast group: Cannot allocate memory
Sep 10 08:33:34 dnsmasq[452798]: try increasing /proc/sys/net/core/optmem_max
Sep 10 08:33:34 dnsmasq[452798]: interface veth7d8cee4 failed to join DHCPv6 multicast group: Cannot allocate memory
Sep 10 08:33:35 dnsmasq-dhcp[452798]: DHCP packet received on veth7d8cee4 which has no address
Sep 10 08:33:35 dnsmasq-dhcp[452798]: DHCP packet received on veth7d8cee4 which has no address
Sep 10 08:33:35 dnsmasq-dhcp[452798]: RTR-SOLICIT(docker0) 02:42:79:24:3c:97
Sep 10 08:33:35 dnsmasq-dhcp[452798]: no address range available for DHCP request via docker0
Sep 10 08:33:36 dnsmasq[452798]: listening on vethdf2b4b7(#6203): xxxxxxxx%vethdf2b4b7 port 53
Sep 10 08:37:13 dnsmasq[600289]: started, version pi-hole-2.81 cachesize 10000
Sep 10 08:37:13 dnsmasq[600289]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile
Sep 10 08:37:13 dnsmasq[600289]: DNSSEC validation enabled
Sep 10 08:37:13 dnsmasq[600289]: configured with trust anchor for <root> keytag 20326
Sep 10 08:37:13 dnsmasq-dhcp[600289]: DHCP, IP range 192.168.1.20 -- 192.168.1.251, lease time 1d
Sep 10 08:37:13 dnsmasq-dhcp[600289]: DHCPv6, IP range ::100 -- ::1ff, lease time 1d, template for enp3s0
Sep 10 08:37:13 dnsmasq-dhcp[600289]: DHCPv4-derived IPv6 names on enp3s0
Sep 10 08:37:13 dnsmasq-dhcp[600289]: router advertisement on enp3s0
Sep 10 08:37:13 dnsmasq-dhcp[600289]: DHCPv6, IP range xxxxxxxx, lease time 1d, constructed for enp3s0
Sep 10 08:37:13 dnsmasq-dhcp[600289]: DHCPv4-derived IPv6 names on xxxxxx, constructed for enp3s0
Sep 10 08:37:13 dnsmasq-dhcp[600289]: router advertisement on xxxxxx, constructed for enp3s0
Sep 10 08:37:13 dnsmasq-dhcp[600289]: DHCPv6, IP range xxxxxxx -- xxxxxxx, lease time 1d, constructed for enp3s0
Sep 10 08:37:13 dnsmasq-dhcp[600289]: DHCPv4-derived IPv6 names on xxxxxxx, constructed for enp3s0
Sep 10 08:37:13 dnsmasq-dhcp[600289]: router advertisement on xxxxxxx, constructed for enp3s0
Sep 10 08:37:13 dnsmasq-dhcp[600289]: RTR-ADVERT(enp3s0) xxxxxxx
Sep 10 08:37:13 dnsmasq-dhcp[600289]: RTR-ADVERT(enp3s0) xxxxxxx
Sep 10 08:37:13 dnsmasq[600289]: using only locally-known addresses for domain use-application-dns.net
Sep 10 08:37:13 dnsmasq[600289]: using nameserver 2606:4700:4700::1001#53
Sep 10 08:37:13 dnsmasq[600289]: using nameserver 2606:4700:4700::1111#53
Sep 10 08:37:13 dnsmasq[600289]: using nameserver 1.0.0.1#53
Sep 10 08:37:13 dnsmasq[600289]: using nameserver 1.1.1.1#53
Sep 10 08:37:13 dnsmasq[600289]: read /etc/hosts - 7 addresses
Sep 10 08:37:13 dnsmasq[600289]: read /etc/pihole/custom.list - 2 addresses
Sep 10 08:37:13 dnsmasq[600289]: read /etc/pihole/local.list - 4 addresses
Sep 10 08:37:13 dnsmasq-dhcp[600289]: RTR-ADVERT(enp3s0) xxxxxxx
Sep 10 08:37:13 dnsmasq-dhcp[600289]: RTR-ADVERT(enp3s0) xxxxxxx
Sep 10 08:37:13 dnsmasq[600289]: listening on vethe5b89d2(#6271): xxxxxxxx%vethe5b89d2 port 53

The pihole-FTL process (responsible for DNS) wasn't bound to port 53 at the time of debug log creation:

*** [ DIAGNOSING ]: Pi-hole processes
[✓] lighttpd daemon is active
[✓] pihole-FTL daemon is active

*** [ DIAGNOSING ]: Ports in use
*:631 cupsd (IPv4)
*:631 cupsd (IPv6)
*:7878 mono (IPv4)
*:8989 mono (IPv4)
*:58249 transmissi (IPv4)
*:58249 transmissi (IPv6)
*:9091 transmissi (IPv4)
127.0.0.1:41941 containerd (IPv4)
*:9117 jackett (IPv6)
*:3000 grafana-se (IPv6)
127.0.0.1:8088 influxd (IPv4)
*:8086 influxd (IPv6)
*:22 sshd (IPv4)
*:22 sshd (IPv6)
[80] is in use by lighttpd
[80] is in use by lighttpd
*:6767 python3 (IPv4)
*:445 smbd (IPv6)
*:139 smbd (IPv6)
*:445 smbd (IPv4)
*:139 smbd (IPv4)
*:8096 jellyfin (IPv6)

In addition, your Pi-hole seems to reject a large amount of telnet API requests due to excessive client requests (showing just examples of a few dozen entries here):

*** [ DIAGNOSING ]: contents of /var/log

-rw-r--r-- 1 pihole pihole 20877 Sep 10 08:33 /var/log/pihole-FTL.log
   -----head of pihole-FTL.log------
   [2020-09-10 00:00:31.006 259960/T259962] Client denied (at max capacity of 255): 341

   -----tail of pihole-FTL.log------
   [2020-09-10 08:20:07.365 452798/T452799] Client denied (at max capacity of 255): 795

It's not necessarily that this would be the cause, but it may help to identify the source of those unusual high amount of telnet access requests and try to tune that down.

Also, that specific log excerpt available from the debug log does not show anything beyond those errors, but /var/log/pihole-FTL.log may contain additional information.
You should try and correlate the time of your perceived outage with that log and see if it contains any hints as to why Pi-hole would stop listening for DNS requests.

port 53 not being bound is probably a symptom rather than a cause.

I had trouble with docker (specifically this issue) at the same moments when pihole wasn't working I assume they are related as I no longer have any issues now.