Pihole freezing randomly (apparently)

letivre · February 1, 2022, 5:40am

Hi there,

I am new to the forum and using pihole. I have been struggling to make it work for the past 2 days, it worked well for ~3 days but now I am having issues.
Truly appreciate your guidance/help with this issue.

It freezes (not able to access the portal pihole/admin)
DNS resolution stops
See attached debug logs: [✓]:

1. -  Your debug token is: https://tricorder.pi-hole.net/HzBb9EO2/
2. -  Your debug token is: https://tricorder.pi-hole.net/DDl3BaNR/   --> 
Not able to access pihole UI with error: DNS_PROBE_FINISHED_NXDOMAIN

Once pihole gets in this state, I noticed the following:
-- I can't access the UI
-- It stops filtering ads (I can see all adds in my phone via flipboard app).
-- nslookup fails

# pihole status result:

    -- $ pihole status shows everything up and running
          root@9cbf:/# pihole status
            [✓] FTL is listening on port 53
               [✓] UDP (IPv4)
               [✓] TCP (IPv4)
               [✓] UDP (IPv6)
               [✓] TCP (IPv6)

          [✓] Pi-hole blocking is enabled

nslookup yahoo.com result

C:\Users\me>nslookup yahoo.com
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.168.0.xxx   --> Correct pihole private ip address

DNS request timed out.
    timeout was 2 seconds.

Also below compose.yml

#    image: pihole/pihole:latest
  pihole:
    container_name: pihole
    restart: unless-stopped
    image: pihole/pihole:latest
    shm_size: '1g'
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - PiPASSWORD=${PiPASSWORD}

      # Cloudflared container
      - PIHOLE_DNS_=172.30.x.x#5053   #FER: comment out once update >v5.6
      - "DNS2=no"

      - "DNSMASQ_LISTENING=all"

    volumes:
      - ${USERDIR}/docker/apps/pihole/config:/etc/pihole/
      - ${USERDIR}/docker/apps/shared:/shared
      - ${USERDIR}/docker/apps/pihole/dnsmasq:/etc/dnsmasq.d/'

    cap_add:
      - NET_ADMIN

    networks:
      internal:
        ipv4_address: 172.30.x.x
      p_lan:
        ipv4_address: 192.168.0.xxx

    depends_on:
      - cloudflared

networks:
  internal:
    ipam:
      config:
        - subnet: 172.30.x.x/29

#FER: 1/21/2022
# Creating macvlan
  p_lan:
    driver: macvlan
    driver_opts:
      parent: enx0a1
    ipam:
      config:
        - subnet: 192.168.0.0/24
          gateway: 192.168.0.1
          ip_range: 192.168.0.240/28

Appreciate your help and attention,

MM.

Bucking_Horn · February 1, 2022, 9:24pm

Run from your Windows client, what's the output of:

nslookup flurry.com

letivre · February 2, 2022, 5:08am

I re-started the container recently, so everything is up and running right now. I will have to wait for the system to fail.

Either way, right now (when everything is ok) the output of that command is:

C:\Users\me>nslookup flurry.com
Server:  pi.hole
Address:  192.168.0.242

Name:    flurry.com
Addresses:  ::
          0.0.0.0

letivre · February 2, 2022, 8:01am

Here the results:

C:\Users\me>nslookup flurry.com
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.168.0.242

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.

Bucking_Horn · February 2, 2022, 9:23am

The Server: UnKnown in your nslookups (which should normally read pi.hole) is caused by a custom configuration you applied to your Pi-hole:

*** [ DIAGNOSING ]: contents of /etc/pihole

-rw-r--r-- 1 pihole pihole 20 Jan 31 21:50 /etc/pihole/pihole-FTL.conf
   REPLY_ADDR4=0.0.0.0

This would explain inability to access Pi-hole's web interface from clients.
Remove that line or provide a valid IPv4 address.

Also, your HzBb9EO2 debug log shows your router is distributing itself as DNS server along with Pi-hole:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   * Received 317 bytes from eth1:192.168.0.1
     Offered IP address: 192.168.0.110
     Server IP address: 192.168.0.1
     DHCP options:
      Message type: DHCPOFFER (2)
      netbios-ns: 192.168.0.1
      dns-server: 192.168.0.242
      dns-server: 192.168.0.1
      dns-server: 192.168.0.1
      router: 192.168.0.1

Pi-hole has to be the only DNS server in your network.
Make sure your router's DHCP server is configured to hand out Pi-hole exclusively for DNS.

Furthermore, both your debug logs show that neither your Docker container itself nor Pi-hole can access (public) upstream DNS resolvers:

*** [ DIAGNOSING ]: Operating system
[i] Pi-hole Docker Container: 2022.01.1
[i] dig return code:  9
[i] dig response:  ;; connection timed out; no servers could be reached

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] al.office-com.jp is 0.0.0.0 on lo (127.0.0.1)
[✓] No IPv4 address available on eth0@if40
[✓] No IPv4 address available on eth1@if28
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (8.8.8.8)

The timeouts of the container itself (which is using Docker's internal 127.0.0.11 for DNS) could indicate a general issue with your host's DNS service, e.g. your host machine's firewall blocking port 53/DNS.

The timeouts for Pi-hole may also be explained by your upstream cloudflared container failing to provide resolution.
Pi-hole's logs should reveal whether Pi-hole would be waiting for a response from cloudflared.
If that's the case, change Pi-hole's upstream to a DNS server that is accessible.

letivre · February 3, 2022, 6:53am

Thanks much for the response and details - A few points:

FTL-conf: This entry is/was added automatically by pihole.


*** [ DIAGNOSING ]: contents of /etc/pihole

-rw-r--r-- 1 pihole pihole 20 Jan 31 21:50 /etc/pihole/pihole-FTL.conf
   REPLY_ADDR4=0.0.0.0

Completed the following changes:
2.1. Set pihole as the only DNS server in the local network.
2.2. Adjusted resolved.conf to point to pihole ip address and resolv.conf to ensure it points to 127.0.0.11 as nameserver.

Those steps now are allowing me to perform nslookups from host and pihole container without issues.

A couple of questions remain:

Why are these services inactive?


*** [ DIAGNOSING ]: Pi-hole processes
[✗] lighttpd daemon is inactive
[✗] pihole-FTL daemon is inactive

Also, what I see @ pihole log.

> [services.d] done.
> Stopping pihole-FTL
> 
> kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
> 
> Starting pihole-FTL (no-daemon) as pihole

DNS resolution is bound to eht0 as expected. Pihole should not be able to access upstream servers via port 53 on any other adapter. The goal is to have pihole move all requests via DoH to upstream servers through the cloudflared tunnel. Cloudflared runs in semi-isolation on the same private subnet as pihole so they can talk to each other. I am using - PIHOLE_DNS_=172.30.9.2#5053 to point pihole to cloudflared service and tunnel for upstream servers. Is that a problem?

*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
    172.30.9.3/29

Attaching another log

[✓] Your debug token is: https://tricorder.pi-hole.net/WlYF214p/

Thanks much,
FA.

Bucking_Horn · February 3, 2022, 8:52am

Ah, indeed - and your debug log shows this to be set to 0.0.0.0 again.
That seems to be a known issue (#956) with dockered Pi-hole if you do not provide the recommended FTLCONF_REPLY_ADDR4.

Please set FTLCONF_REPLY_ADDR4 as Environment Variable in your docker-compose file.

They are not.
Those readings may just not be reliable within virtualised environments, e.g. Docker restrictions makes the debug script report them as inactive for containers.

I can't comment much on your "@ pihole log", as I do not see any respective lines in your debug log.

No, as long as that IP address and port are accessible to Pi-hole.
But note that successful DNS resolution would depend on cloudflared, and we've seen some few reports for cloudflared being temporarily unreliable at times in the past (though I'm not aware of any recent issues).

In general, it shouldn't be necessary to touch those settings.

Pi-hole's operation itself doesn't depend on them: Pi-hole will use its configured upstreams exclusively. resolv.conf would thus only be relevant for other DNS resolution activities from within your container, e.g. for a manual nslookup (again, from within your container) or a debug script run (pihole -up would be affected, too, but that's not relevant for a container, as pulling a recent image is the correct way to update your Docker Pi-hole)..

I should also mention that we had a few rare reports where resolution issues on container restarts could be mitigated by explicitly providing container internal DNS servers. If you have to set them, use the respective Docker arguments (--dns) for your container.