DNS periodically stops replying

Multiple times a day, devices on my network stop being able to load web sites. When this occurs, I'm also unable to ping domains, but pinging IPs works fine. I believe what's happening is that DNS resolution stops working. I have a Raspberry Pi running Pi-hole taking care of DNS for my network. Restarting the Raspberry Pi is usually required to resolve this situation, though sometimes it solves itself within a few minutes. This has been happening since around the time I installed Pi-Hole v5.15.

When I tailed pihole.log, I noticed that I stop seeing "reply" log lines and instead see lots of "query" and "forwarded" log lines.

Before problem occurred:

Mar 26 13:32:35: query[HTTPS] api-partner.spotify.com from 10.0.1.16
Mar 26 13:32:35: forwarded api-partner.spotify.com to 208.67.220.220
Mar 26 13:32:35: query[A] api-partner.spotify.com from 10.0.1.16
Mar 26 13:32:36: forwarded api-partner.spotify.com to 208.67.220.220
Mar 26 13:32:36: reply api-partner.spotify.com is NODATA
Mar 26 13:32:36: reply api-partner.spotify.com is <CNAME>
Mar 26 13:32:36: reply partners.wg.spotify.com is <CNAME>
Mar 26 13:32:36: reply edge-web.dual-gslb.spotify.com is 35.186.224.25
Mar 26 13:32:36: query[HTTPS] postimg.cc from 10.0.1.16
Mar 26 13:32:36: forwarded postimg.cc to 208.67.220.220
Mar 26 13:32:36: query[A] postimg.cc from 10.0.1.16
Mar 26 13:32:36: forwarded postimg.cc to 208.67.220.220
Mar 26 13:32:36: reply postimg.cc is NODATA
Mar 26 13:32:36: reply postimg.cc is 46.229.175.90
Mar 26 13:32:36: query[HTTPS] postimgs.org from 10.0.1.16
Mar 26 13:32:36: forwarded postimgs.org to 208.67.220.220
Mar 26 13:32:36: query[A] postimgs.org from 10.0.1.16
Mar 26 13:32:36: forwarded postimgs.org to 208.67.220.220
Mar 26 13:32:36: reply postimgs.org is NODATA
Mar 26 13:32:36: reply postimgs.org is 104.21.43.29
Mar 26 13:32:36: reply postimgs.org is 172.67.216.170
Mar 26 13:32:36: query[HTTPS] i.postimg.cc from 10.0.1.16
Mar 26 13:32:36: forwarded i.postimg.cc to 208.67.220.220
Mar 26 13:32:38: query[HTTPS] i.postimg.cc from 10.0.1.16
Mar 26 13:32:38: forwarded i.postimg.cc to 208.67.222.222
Mar 26 13:32:38: forwarded i.postimg.cc to 208.67.220.220
Mar 26 13:32:38: reply i.postimg.cc is NODATA

While problem was occurring:

Mar 26 13:32:54: query[A] czfe58-front01-iad01.transport.home.nest.com from 10.0.0.4
Mar 26 13:32:54: forwarded czfe58-front01-iad01.transport.home.nest.com to 208.67.222.222
Mar 26 13:32:54: forwarded czfe58-front01-iad01.transport.home.nest.com to 208.67.220.220
Mar 26 13:32:54: query[AAAA] czfe58-front01-iad01.transport.home.nest.com from 10.0.0.4
Mar 26 13:32:54: forwarded czfe58-front01-iad01.transport.home.nest.com to 208.67.222.222
Mar 26 13:32:54: forwarded czfe58-front01-iad01.transport.home.nest.com to 208.67.220.220
Mar 26 13:33:09: query[HTTPS] api.mixpanel.com from 10.0.1.2
Mar 26 13:33:09: forwarded api.mixpanel.com to 208.67.222.222
Mar 26 13:33:09: query[A] api.mixpanel.com from 10.0.1.2
Mar 26 13:33:09: gravity blocked api.mixpanel.com is 0.0.0.0
Mar 26 13:33:10: query[HTTPS] api.mixpanel.com from 10.0.1.2
Mar 26 13:33:10: forwarded api.mixpanel.com to 208.67.222.222
Mar 26 13:33:10: forwarded api.mixpanel.com to 208.67.220.220
Mar 26 13:33:14: query[HTTPS] apps.mzstatic.com from 10.10.10.205
Mar 26 13:33:14: forwarded apps.mzstatic.com to 208.67.222.222
Mar 26 13:33:14: query[A] apps.mzstatic.com from 10.10.10.205
Mar 26 13:33:14: forwarded apps.mzstatic.com to 208.67.222.222
Mar 26 13:33:15: query[HTTPS] apps.mzstatic.com from 10.10.10.205
Mar 26 13:33:15: forwarded apps.mzstatic.com to 208.67.222.222
Mar 26 13:33:15: forwarded apps.mzstatic.com to 208.67.220.220
Mar 26 13:33:15: query[A] apps.mzstatic.com from 10.10.10.205
Mar 26 13:33:15: forwarded apps.mzstatic.com to 208.67.222.222
Mar 26 13:33:15: forwarded apps.mzstatic.com to 208.67.220.220
Mar 26 13:33:18: query[A] czfe58-front01-iad01.transport.home.nest.com from 10.0.0.4
Mar 26 13:33:18: forwarded czfe58-front01-iad01.transport.home.nest.com to 208.67.222.222
Mar 26 13:33:18: query[AAAA] czfe58-front01-iad01.transport.home.nest.com from 10.0.0.4
Mar 26 13:33:18: forwarded czfe58-front01-iad01.transport.home.nest.com to 208.67.222.222
Mar 26 13:33:26: query[AAAA] hermes-prd.sn.tesla.services from 10.10.10.105
Mar 26 13:33:26: forwarded hermes-prd.sn.tesla.services to 208.67.222.222
Mar 26 13:33:26: query[A] hermes-prd.sn.tesla.services from 10.10.10.105
Mar 26 13:33:26: forwarded hermes-prd.sn.tesla.services to 208.67.222.222

[...]

Looking at the Pi-hole debug log, a few things stand out:

While problem is happening:

*** [ DIAGNOSING ]: Operating system
[i] Distro: Debian
[i] Version: 11
[✗] dig return code: 10
[✗] dig response: dig: couldn't get address for 'ns1.pi-hole.net': failure
[✗] Error: dig command failed - Unable to check OS

After problem is resolved:

*** [ DIAGNOSING ]: Operating system
[✓] Distro:  Debian
[✓] Version: 11
[✓] dig return code: 0
[i] dig response: "Raspbian=10,11 Ubuntu=20,22 Debian=10,11 Fedora=36,37 CentOS=8,9"
[✓] Distro and version supported

While problem is happening (way more UDP ports in use):

*** [ DIAGNOSING ]: Ports in use
    udp:0.0.0.0:631 is in use by cups-browsed
    udp:0.0.0.0:49286 is in use by pihole-FTL
    udp:0.0.0.0:33419 is in use by pihole-FTL
    udp:0.0.0.0:53389 is in use by pihole-FTL
    udp:0.0.0.0:49294 is in use by pihole-FTL
    udp:0.0.0.0:41619 is in use by pihole-FTL
    udp:0.0.0.0:33948 is in use by pihole-FTL
    udp:0.0.0.0:41121 is in use by pihole-FTL
    udp:0.0.0.0:59044 is in use by pihole-FTL
    udp:0.0.0.0:58047 is in use by pihole-FTL
    udp:0.0.0.0:39635 is in use by pihole-FTL
    udp:127.0.0.1:5335 is in use by unbound
    udp:0.0.0.0:5353 is in use by avahi-daemon
    udp:0.0.0.0:60650 is in use by pihole-FTL
    udp:0.0.0.0:44788 is in use by pihole-FTL
    udp:0.0.0.0:58104 is in use by pihole-FTL
    udp:0.0.0.0:33039 is in use by pihole-FTL
    udp:0.0.0.0:42266 is in use by pihole-FTL
    udp:0.0.0.0:56112 is in use by pihole-FTL
    udp:0.0.0.0:47930 is in use by pihole-FTL
    udp:0.0.0.0:60731 is in use by pihole-FTL
    udp:0.0.0.0:56139 is in use by pihole-FTL
    udp:0.0.0.0:40780 is in use by pihole-FTL
    udp:0.0.0.0:55630 is in use by pihole-FTL
    udp:0.0.0.0:39769 is in use by avahi-daemon
    udp:0.0.0.0:42857 is in use by pihole-FTL
    udp:0.0.0.0:59802 is in use by pihole-FTL
    udp:0.0.0.0:59813 is in use by pihole-FTL
    udp:0.0.0.0:33714 is in use by pihole-FTL
    udp:0.0.0.0:53174 is in use by pihole-FTL
    udp:0.0.0.0:42422 is in use by pihole-FTL
    udp:0.0.0.0:57282 is in use by pihole-FTL
    udp:0.0.0.0:36837 is in use by pihole-FTL
    udp:0.0.0.0:46081 is in use by pihole-FTL
    udp:0.0.0.0:46624 is in use by pihole-FTL
    udp:0.0.0.0:41007 is in use by pihole-FTL
[✓] udp:0.0.0.0:53 is in use by pihole-FTL
    udp:0.0.0.0:34361 is in use by pihole-FTL
    udp:0.0.0.0:68 is in use by dhcpcd
    udp:*:46246 is in use by avahi-daemon
    udp:*:5353 is in use by avahi-daemon
[✓] udp:*:53 is in use by pihole-FTL
    tcp:127.0.0.1:5335 is in use by unbound
[✓] tcp:0.0.0.0:53 is in use by pihole-FTL
    tcp:127.0.0.1:8953 is in use by unbound
    tcp:0.0.0.0:22 is in use by sshd
[✓] tcp:0.0.0.0:80 is in use by lighttpd
    tcp:127.0.0.1:631 is in use by cupsd
[✓] tcp:127.0.0.1:4711 is in use by pihole-FTL
    tcp:0.0.0.0:5900 is in use by vncserver-x11-c
    tcp:0.0.0.0:9100 is in use by docker-proxy
[✓] tcp:[::]:53 is in use by pihole-FTL
    tcp:[::]:22 is in use by sshd
[✓] tcp:[::]:80 is in use by lighttpd
    tcp:[::]:5900 is in use by vncserver-x11-c
[✓] tcp:[::1]:4711 is in use by pihole-FTL
    tcp:[::1]:631 is in use by cupsd
    tcp:[::]:9100 is in use by docker-proxy

After problem is resolved:

*** [ DIAGNOSING ]: Ports in use
    udp:0.0.0.0:631 is in use by cups-browsed
    udp:127.0.0.1:5335 is in use by unbound
    udp:0.0.0.0:5353 is in use by avahi-daemon
    udp:0.0.0.0:39769 is in use by avahi-daemon
[✓] udp:0.0.0.0:53 is in use by pihole-FTL
    udp:0.0.0.0:68 is in use by dhcpcd
    udp:*:46246 is in use by avahi-daemon
    udp:*:5353 is in use by avahi-daemon
[✓] udp:*:53 is in use by pihole-FTL
    tcp:127.0.0.1:5335 is in use by unbound
[✓] tcp:0.0.0.0:53 is in use by pihole-FTL
    tcp:127.0.0.1:8953 is in use by unbound
    tcp:0.0.0.0:22 is in use by sshd
[✓] tcp:0.0.0.0:80 is in use by lighttpd
    tcp:127.0.0.1:631 is in use by cupsd
[✓] tcp:127.0.0.1:4711 is in use by pihole-FTL
    tcp:0.0.0.0:5900 is in use by vncserver-x11-c
    tcp:0.0.0.0:9100 is in use by docker-proxy
[✓] tcp:[::]:53 is in use by pihole-FTL
    tcp:[::]:22 is in use by sshd
[✓] tcp:[::]:80 is in use by lighttpd
    tcp:[::]:5900 is in use by vncserver-x11-c
[✓] tcp:[::1]:4711 is in use by pihole-FTL
    tcp:[::1]:631 is in use by cupsd
    tcp:[::]:9100 is in use by docker-proxy

The debug log while the problem happened failed to upload. Here's a debug log once the problem resolved itself: https://tricorder.pi-hole.net/6cmuDp85/.

Any help diagnosing/debugging this issue would be greatly appreciated!

This indicates that the issue is with Pi-hole's upstream DNS servers, rather than Pi-hole:
Your chosen upstreams do not reply in time or not at all.
This would also explain why the debug log's OS lookup fails, provided your Pi-hole host machine would also be using the same upstream resolvers, directly or indirectly.

If this persists, you could consider to use another upstream DNS server, either in addition or instead of your current one(s).

Hrm, interesting! I've been using OpenDNS as my upstream DNS servers. I'll try out Cloudfare for debugging to see if that helps.

Since switching to Cloudfare, I've stopped having these DNS problems. I appreciate the help!