Resolved (Not a PiHole issue) - Losing Internet every 12 hours due to DNS issues

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

Expected Behaviour:

Not having to restart my PiHole device every 12 hours

Actual Behaviour:

Installed Pihole and updated to the Dev branch to test out FTL and also use DNSCrypt-Proxy2.0. Every ~12 hours I am having to restart my PiHole device (Odroid XU4 with Ubuntu 18.04) due to not being able resolve any host names. After the reboot I am able to successfully browse the internet again.

I know that it is every 12 hours because the DNS queries spike up in the PiHole interface due to some of my network devices constantly checking for an internet connection (mostly Google home and my work laptop).

I am not sure if this is an issue with PiHole or with DNSCrypt-Proxy 2.0 so I apologize in advance if this is unrelated to PiHole.

Debug Token:

c9wiqskea5

Do you have Network Manager installed?

check with which NetworkManager

If you do, then the culprit might be Network Manager and it's forced dnsmasq reload.

The dev brach requires dnsmasq to be disabled in order for FTLDNS to work.

If dnsmasq gets activated, it breaks FTL and no queries will go through.

In order to disable dnsmasq from Network Manager, you'd have to edit /etc/NetworkManager/NetworkManager.conf and comment out dns=dnsmasq

( sudo sed -i 's/^dns=dnsmasq/#&/' /etc/NetworkManager/NetworkManager.conf )

then restart the network manager and networking:

sudo service network-manager restart
sudo service networking restart

Kill dnsmasq sudo killall dnsmasq

and restart FTL

sudo systemctl restart pihole-FTL

It looks like Network Manager is installed but there is nothing in the config file related to dns.

add the #dns=dnsmasq under [main].
(this actually does absolutely nothing)

then restart network manager and networking.

Is your Pi-hole working now ?

If not, what's the output of:

sudo systemctl status dnsmasq
sudo systemctl status pihole-FTL

If it does work, then run these 2 commands when failure occurs and save the output and paste it in this port so that we can see why it fails.

Things are working at the moment but I added the line to NetworkManager.conf and restarted everything as requested.

The next time the issue occurs (should be around 12:30AM) I'll get the output from the commands and post it here.

Thank you for your help so far.

I just realized that adding #dns=dnsmasq does absolutely nothing.

What you could do is remove dnsmasq (since the Development branch doesn't need it), unless you use dnsmasq for your own configuration, in wich case, waiting for the output of the above commands during an error, is needed.

It might be something else too, possible related to file permissions ...

I'm fine with removing it since I don't use it for anything else and I don't believe DNSCrypt-Proxy2.0 needs it.

Remember to check the config after dnsmasq uninstall:

No luck, my ability to resolve host names stopped at 6:30PM.

What does nslookup flurry.com return on the pi-hole device when DNS resolving fails on your devices?

Run the same command on a failing device.

If connected via Wifi, check if "Power Management" is enabled/on with:

iwconfig

Check for RX and TX errors with below one:

ifconfig

Just as a side note: As the dashboard is showing these queries, it cannot be a Pi-hole problem, as FTLDNS wouldn't be able to record the spike of queries when it isn't working. Check the logs in /var/log/pihole.log at the time of the failure. I'm expecting that the queries get forwarded to your dnscrypt instance which does not reply

I’m having a similar issue, using an ODROID C2. Are you able to remote in/ping the ODROID when your DNS goes down? I can’t do either for mine. A few mins later it starts working.

Performing the nslookup helped me pinpoint the issue. It was definitely related to DNSCrypt Proxy.

I went into the config of DNSCrypt and disabled that feature. Fingers crossed that the issue has been resolved.

Thanks @RamSet and DL6ER for your help even though this was not a PiHole issue.

@FutureTense I was still able to remote into my Odroid. If you are using WiFi then I'd recommend following deHakkelaar's suggestion. I had a similar issue with an Raspberry Pi acting as a server for an IoT project and disabling WiFi power management resolved the issue. You will want to create a script to run at each boot to disable the power management because it is reenabled after each reboot.

3 Likes

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