Thank you. If I can get it to crash again, I will post the debug log and token.
Below are the errors from the logs.
In the meantime, would you please point me to a bit more specific instruction on how to set up the order control?
Many thanks!
Errors:
From pihole.log:
Mar 9 00:05:14 dnsmasq[897]: reply error is SERVFAIL
Mar 9 03:05:10 dnsmasq[897]: reply error is SERVFAIL
Mar 9 06:05:20 dnsmasq[897]: reply error is SERVFAIL
Mar 9 08:42:18 dnsmasq[897]: reply error is SERVFAIL
[Several more just like this]
Thank you. My main question is in which file am I supposed to set the DNS server order? Do I set the order in the 01-pihole.conf file in /etc/dnsmasq.d? That file lists the DNS servers.
I should add that it isn't obvious where I should set the order in /etc/resolv.conf (as noted in the link you provided in the strict-order description), hence the question.
I believe I have properly implemented the "strict-order" flag as follows.
I added the "strict-order" flag to the 01-pihole.conf file in /etc/dnsmasq.d.
That didn't seem to work, so I created a file called strict-order.conf and added the flag to that file.
After doing this, my 127.0.0.1 server was prioritized with any other DNS servers selected receiving less traffic. So the flag seems to be having an effect.
Also check that the date/time on the Pi matches the correct local time. DNSSEC depends on accurate time for the authentication algorithm to work properly, and if Cloudflared is using that, it will need accuracy.
With Pi-Hole as your DNS resolver, /etc/resolv.conf should use only nameserver 127.0.0.1. This routes all Pi DNS traffic to Pi-Hole, and then Pi-Hole uses its assigned upstream servers. If you had multiple servers in the resolv.conf, then at least some of the traffic will bypass Pi-Hole.
I don't know how to define a priority order in this file without potentially bypassing Pi-hole. I'll defer to one of the developers (@dl6er in particular) for that answer.
If you can't get Cloudflared to behave properly, unbound is a good option. Runs locally on the Pi, no upstream resolver, and I've never had it fail and I run four instance of it on various Pi-Holes.
No problems with unbound speed. It has a very efficient cache and caches information behind the scenes. For example, it keeps quite a bit of authoritative nameserver data in cache, so it typically doesn't need to communicate with the top servers very often. I also find that the TTLs for most domains I look up with unbound are much longer than the TTL provided by the commercial DNS servers, so that keeps data in cache longer as well.
With DNSSEC enabled in unbound (default per the configuration guide I referenced), security is equal to DoH and I think unbound provides better privacy since no upstream DNS server has all your DNS history.
mask NAME...
Mask one or more units, as specified on the command line. This will link these unit files to /dev/null, making it impossible to start them. This is a stronger version of disable, since it prohibits all kinds
of activation of the unit, including enablement and manual activation. Use this option with care. This honors the --runtime option to only mask temporarily until the next reboot of the system. The --now option
may be used to ensure that the units are also stopped. This command expects valid unit names only, it does not accept unit file paths.
This should be possible but I haven't tried it myself for a few years so I'm not sure if it still works as expected (it should, though).
Create a file /etc/dnsmasq.d/99-custom.conf and put there:
strict-order
/etc/resolv.conf should still only be:
nameserver 127.0.0.1
Then ensure that the servers are in the correct order in /etc/dnsmasq.d/01-pihole.conf (first listed = first asked) and run
pihole restartdns
However, I haven't found it necessary to define a fallback solution for Unbound which is working 100% perfect for me since years in a mid-business sizes environment.