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.
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 ...
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.
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.