PiHole hangs randomly, causing delays in loading web pages

Help
1

Expected Behaviour:

Set my raspberry pi's IP address as the DNS server for clients, iPhone and Windows PC. There should be no interrptions in internet browsing.

Actual Behaviour:

Web pages occasionally take long time to load, if they do load. iPhone client seems to wait for DNS to response, waiting upwards of 1min 30 sec, while PC will stop loading the webpage with some variation of dns_probe_started, dns_probe_finished_nxdomain, or dns_probe_finished_bad_config.

Debug Token:

https://tricorder.pi-hole.net/4E0FVC52/

There was a disruption in service Jul 25 7:29:18, with nothing written to logs until Jul 25 7:30:42. At 7:30:42, 162 log entries were written at the exact same time. Another observation is that PiHole will reply with NODATA to a domain but immediately write to the log that it replied with a real IP.

I've used this modem, router, and pi combo for the last 4 or so years without problems, but I moved to a new home and now I am having problems. Clients manually specify the DNS server, I do not want the PiHole to be my DHCP server nor do I want to configure my router to use PiHole as its DNS server. (Again, I've ran this exact setup for years with no problems, please do not try to convince me otherwise)

During the outage, performing nslookup pi.hole on a client times out.

2

Most often, when Pi-hole registers no DNS messages in its logs, that would not happen because Pi-hole isn't operational, but rather because clients do not or cannot send DNS requests to your Pi-hole.

The former may be the case e.g. if clients by-pass Pi-hole via an alternative DNS resolver, the latter may happen if the network connection to Pi-hole would be blocked or severed, e.g. if the host's wifi network interface would be disabled upon entering a power saving mode.

Your debug log shows no signs of outages.
In particular, there are no messages in Pi-hole's diagnostic section:

*** [ DIAGNOSING ]: Pi-hole diagnosis messages

Short periods of outages for clients commonly can be correlated with rate-limitiing or maximum utilisation of concurrent threads, both of which would have prompted a respective diagnostic message.
Those messages would be cleared on Pi-hole restart, and they can also be cleared manually.

Did you restart Pi-hole or clear any messages before creating the debug log?

To narrow down possible causes for your observation, can you ping your Pi-hole host machine by IP during such an outage?

And to probe for possible by-passes, what's the complete output of

nslookup pi.hole

To that same end, run from a Windows client, what does the following command return as DNS servers:

ipconfig /all

We'd be only interested in the DNS server section of that output.

Both of the former results (i.e. nslookup and ipconfig) may be helpful at any time, not only during outages, so please share them if possible.

That wouldn't be unusual at all.
Two different types of replies usually mean two separate DNS requests.

Your debug log e.g. shows an (incomplete) example for such two types of replies:

*** [ DIAGNOSING ]: Pi-hole log
-rw-r----- 1 pihole pihole 1.2M Jul 25 07:56 /var/log/pihole/pihole.log
   -----tail of pihole.log------
   (...)
   Jul 25 07:56:30 dnsmasq[4559]: cached a2047.dscapi9.akamai.net is 23.66.3.83
   (..)
   Jul 25 07:56:30 dnsmasq[4559]: query[HTTPS] a2047.dscapi9.akamai.net from 192.168.0.247
   Jul 25 07:56:30 dnsmasq[4559]: forwarded a2047.dscapi9.akamai.net to 4.2.2.2
   Jul 25 07:56:30 dnsmasq[4559]: reply a2047.dscapi9.akamai.net is NODATA

Here, Pi-hole provides NODATA for a type HTTPS request for a2047.dscapi9.akamai.net, and we also can still glimpse a previous cached IP address reply for a type A request for that domain.
Both replies were correct.

3

Ok, sounds like I need to reclassify this problem, which you eluded to with the lack of evidence in the debug logs. This isn't pihole unable to perform the lookups, this is client requests not reaching pihole?

Nope. I just made note of when a disruption occurred and when it was over and immediately created a debug log. I initially thought it was rate-limiting/utilization related too, so I disabled logging (a while back) but the disruptions kept happening so I turned it back on.

Just my luck, a disruption occurred as I went to look it up!

C:\Users\<>>nslookup pi.hole
Server:  pi.hole
Address:  192.168.0.139

Name:    pi.hole
Addresses:  fe80::4a9b:169d:3b8d:bcc6
          192.168.0.139

C:\Users\<>>nslookup pi.hole
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.168.0.139

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

C:\Users\<>>ping 192.168.0.139

Pinging 192.168.0.139 with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 192.168.0.139: bytes=32 time=6ms TTL=64
Reply from 192.168.0.139: bytes=32 time=2ms TTL=64

Ping statistics for 192.168.0.139:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 6ms, Average = 4ms

I suspect the successful replies from the pihole occurred because it came back "online"

Here is the output of ipconfig /all (with mac addresses scrubbed)

C:\Users\penar>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : Office-PC
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Ethernet:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) I211 Gigabit Network Connection
   Physical Address. . . . . . . . . : B4-2E
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Unknown adapter Local Area Connection:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Private Internet Access Network Adapter
   Physical Address. . . . . . . . . : 00-FF
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Local Area Connection* 1:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter
   Physical Address. . . . . . . . . : AC-67
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Local Area Connection* 2:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter #2
   Physical Address. . . . . . . . . : AE-67
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) Wi-Fi 6 AX200 160MHz
   Physical Address. . . . . . . . . : AC-67
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::333d:3597:4a6c:d638%15(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.0.112(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Tuesday, July 25, 2023 12:12:30 PM
   Lease Expires . . . . . . . . . . : Tuesday, July 25, 2023 2:12:29 PM
   Default Gateway . . . . . . . . . : 192.168.0.1
   DHCP Server . . . . . . . . . . . : 192.168.0.1
   DHCPv6 IAID . . . . . . . . . . . : 128739165
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-26-58-B2-2B-B4-2E-99-AF-D1-36
   DNS Servers . . . . . . . . . . . : 192.168.0.139
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter Bluetooth Network Connection:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Bluetooth Device (Personal Area Network)
   Physical Address. . . . . . . . . : AC-67
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Here's a new debug token to ensure any rate-limiting would have been captured

4

Again, there are no hints of an actual Pi-hole outage or rate-limit events in your debug log.

The time-outs of both your nslookup and DNS requests may indicate a connectivity issue (click for a brief digression)

If you'd had connected your RPi hosting Pi-hole via wifi, I'd suspected that your RPi OS would disable its wifi interface when entering a power save mode.

However, your debug log suggests that while your RPi features both a wired as well as a wired interface, it would be connected via its wired eth0 connection.

Please alert me if it would instead be using wlan0 instead.

Possible reasons for connectivity issues may be additional network equipment like access points or switches.

Your debug log is peculiar in one aspect:

Pi-hole's DHCP test shows three identical replies for its DHCP discover broadcast from the same DHCP server IP. 
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   * Received 300 bytes from eth0:192.168.0.1
     Offered IP address: 192.168.0.139
     Server IP address: 192.168.0.1
     Relay-agent IP address: N/A
     BOOTP server: (empty)
     BOOTP file: (empty)
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.0.1
      lease-time: Infinite
      netmask: 255.255.255.0
      ntp-server: 128.138.140.44
      broadcast: 192.168.0.255
      dns-server: 192.168.0.1
      router: 192.168.0.1
      --- end of options ---
   
   * Received 300 bytes from eth0:192.168.0.1
     Offered IP address: 192.168.0.139
     Server IP address: 192.168.0.1
     Relay-agent IP address: N/A
     BOOTP server: (empty)
     BOOTP file: (empty)
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.0.1
      lease-time: Infinite
      netmask: 255.255.255.0
      ntp-server: 128.138.140.44
      broadcast: 192.168.0.255
      dns-server: 192.168.0.1
      router: 192.168.0.1
      --- end of options ---
   
   * Received 300 bytes from eth0:192.168.0.1
     DHCPOFFER hardware address did not match our own - ignoring packet (not for us)
     DHCPREQUEST chaddr: b8:27:eb:39:92:fe (our MAC address)
     DHCPOFFER   chaddr: 46:af:50:39:92:fe (response MAC address)
   
   * Received 300 bytes from eth0:192.168.0.1
     Offered IP address: 192.168.0.252
     Server IP address: 192.168.0.1
     Relay-agent IP address: N/A
     BOOTP server: (empty)
     BOOTP file: (empty)
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.0.1
      lease-time: 7200 ( 2h )
      renewal-time: 3600 ( 1h )
      rebinding-time: 6300 ( 1h 45m )
      netmask: 255.255.255.0
      ntp-server: 128.138.140.44
      broadcast: 192.168.0.255
      dns-server: 192.168.0.1
      router: 192.168.0.1
      --- end of options ---
   
   DHCP packets received on interface eth0: 3

Would you perhaps run any such additional equipment?

And turning back attention to possible by-passes:
You wouldn't run certain antivirus software packages employing features like AVG Secure DNS or AVAST Real-Site?

5

No anti virus.

I do have a Wifi Extender that is extending the guest network. No clients on the guest network are using PiHole as their DNS servers. I attempted to set up the wifi extender to extend the range of the guest network, by using the same network name and password.

This extension may be the reason why more than 1 DHCP discovery is made, but surely not 3?

6

I didn't follow this train of thought. The RPi does feature ethernet and wireless interfaces, but it is only connected via ethernet directly to the router, not through a network switch or panel.

7

I'm running short of ideas how DNS could be involved.

In any case, your ping results are a clear indication that the connection to your Pi-hole host machine at 192.168.0.139 is not available at times, pointing away from DNS being your root cause - DNS isn't involved when using IPs.

If you ran that ping from a wifi client, that could suggest a wifi issue, where the client device or the router take a few beats before re-establishing a connection.
I don't think your wifi extender is involved, since you state you only use it for your guest network.

If you ran that from a wired client, I'd recommend to check network cable and network equipment.

8

I think sometime this weekend I am going to factory reset my router and leave wifi extender off and try again.

The only time i experience interruptions is when PiHole server is acting as my DNS unfortunately :frowning:

9

Yes, and I'm afraid that this is to be expected when the machine hosting your Pi-hole is unreachable. :frowning:
The same would happen if you would pull the plug on that machine.

10

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