Need to restart pihole-FTL to make DNS resolution work after rebooting the router

Help
1

Please follow the below template, it will help us to help you!

Expected Behaviour:

Pi-hole answers DNS queries from LAN hosts

Actual Behaviour:

DNS queries from LAN hosts work for a while (no more than 24 hours), then they reach the raspberry pi but they do not show up in pihole.log nor they are being answered. DNS resolution itself seems to be working in fact I can use pi-hole via VPN just fine. I tried in many ways to pinpoint the issue:

  • Since the pi-hole acts as a DHCP server I checked ports 67/udp and 547/udp -> they are open
  • I checked if clients are assigned the ip address and the dns -> they are.
  • I checked if queries reach the pihole with tcpdump -> they do (client -> pihole:53, but no answer).
  • I checked if 53/udp is blocked by ufw by adding iptables ... -j LOG just before allowing the port -> it reaches that rule.

Here’s the catch: if I visit the dashboard, it starts working again. I thought that somehow, since the dashboard runs pihole status web, that could restart pihole-FTL maybe?. In fact running pihole -d while not working, shows that queries via dig random_ad_domain @127.0.0.1 work (it shows up in the log), while dig random_ad_domain @pi_hole_lan_ip do not (it doesn’t show). Few seconds later the script does pihole status web and then the next debug session is completely successful, along with queries from the LAN. I’m not sure if this is just a temporal correlation but I’m struggling to find a solution.

Debug Token:

https://tricorder.pi-hole.net/je2yg017qy

There are SERVFAIL queries in the log, but I think those relate to the fact that internet was off during the night.

By the way, while uploading the debug log, I got this error (translated from italian):

/opt/pihole/piholeDebug.sh: row 1151: warning: command substitution: ignored null byte in input
2

I believe your queries are answered by something else (in your case IPV6 DNS to be more exact).

When both IPV6 and IPV4 are present, IPV6 is preferred.

Your current IPV6 does not match the one in setupVars and i believe your router is answering your queries.

3

I’m not sure if that’s the case: when resolution is not working, lan clients can’t resolve at all. In fact, they do ask the pihole but it times out. My ISP modem has IPv6 disabled by default and I the same mismatch warning on another pihole without issues.

I forgot to mention that the “upstream” server is unbound.

4

When the clients fail, try changing within the /admin/ interface from unbound to one of the public ones.

Don't do anything else, just for the sake of testing, bypass unbound.

Then, try the same query on the client, see if that goes through ...

5

Will do that as soon as it stops working again. One more information, in case it’s useful, is that the debug log taken before the one I uploaded, while not working, was the same except for this line:

[x] Failed to resolve ad_domain via Pi-hole (lan_ip)
6

It looks like it stops working when I reboot the router (which happens every day). I did replace unbound with Google DNS as you suggested however a reboot and it doesn't work anymore.

I have no idea why but running echo > /dev/tcp/127.0.0.1/53 makes dns resolution work again immediately.

7

Maybe thw router has a some sort of DNS Rebind protection that is causing issues ...
It’s a very strange issue i’ve never seen before ...

8

I don't know, for now I think I'm going to add a cron job that triggers pihole-FTL with echo or restarts it after the router is up.

9

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