Using redundant Upstream DNS servers w/Cloudflared = Lost Connection to API



I am running the latest version of Pi-Hole (4.2.2/4.2/4.3) on a RPi 3B using Cloudflared w/ over HTTPS (Custom 1 (IPv4)

I would like to add additional Upstream DNS servers for redundancy (OpenDNS and Quad9).

When I select any other DNS server in addition to Custom 1, a short while later, I get the “Lost Connection to API” warning and everything stops working.

I have tried adding strict-order to a .conf file and seems to work for its intended purpose (putting Custom 1 first), but it doesn’t resolve the lost connection error.

Any ideas for how to achieve my desired setup?

Many thanks,




Please generate a debug log, upload it and post the token here.

Also, take a look in the following logs for any errors and post them here:


Note that when you add additional upstream DNS servers, there is no guarantee that much of your DNS traffic will go through Cloudflared. Pi-Hole will identify the best performing DNS server and route the majority of the traffic there. This may negate any advantages that you expect to gain from using encrypted DNS. You would need to continue a strict order control to force the traffic to Cloudflared.



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!


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]

From pihole-FTL.log:
No errors found in log.



Do you have DNSSEC enabled on Pi-Hole?





DNSSEC is not enabled. It doesn’t seem to work with Cloudflared/



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 server was prioritized with any other DNS servers selected receiving less traffic. So the flag seems to be having an effect.



Those separate config files are read and used as one config file. So using an extra file should not make a difference.



What other servers? Those listed in /etc/resolv.conf (which normally has only) or those listed as upstream DNS servers in Pi-Hole?

Your real problem is the SERVFAIL from Cloudflared. Fix that and you won’t need to add more upstream DNS servers.



What other servers?

The two other servers I selected (OpenDNS and Quad9), so those listed as upstream DNS servers in Pi-Hole.

Your real problem is the SERVFAIL from Cloudflared. Fix that and you won’t need to add more upstream DNS servers.

Agreed. Any idea for how to fix this?



I would start with checking all the Cloudflared configuration and settings against this guide:

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.



Thanks. I double checked everything and it all conforms with the setup guide.

Can you shed any light on specifically how I set the order of the DNS servers in /etc/resolv.conf?

Would it work to create a file called server-order.conf and just list them in order?

Many thanks for the help.





With Pi-Hole as your DNS resolver, /etc/resolv.conf should use only nameserver 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.



Thanks, @jfb, I appreciate the help.

I considered Ubound when first setting up the Pi-Hole. The possibility of slow speed led me to use Cloudflared.

What has your experience been with Unbound’s speed?

Thanks again.





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.



Interesting. Thank you for the replies today.

Last question: any idea how to uninstall Cloudflared?





Haven’t done this in a while, but I suspect these might work if the process name is cloudflared

sudo service cloudflared stop

sudo apt-get remove cloudflared



Thank you. I stopped and “masked” (whatever that is) Cloudflared, per another post on Unbound.

I have Unbound up and running right now.

So far, so good.

Thanks again for your help today.



1 Like


From “man systemctl”

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.



Pleased to report Unbound is working well.



1 Like