Why does pihole switche to PIHOLE_DNS_2

Help Community Help
1

The issue I am facing:

I specify a local unbound server as PIHOLE_DNS_1.
I wan't it to use the local unbound server
I specify a QUAD9 server as _DNS_2 for backup purposes

Occasionally pihole decides to use the QUAD9 and will stay "stuck" using that
until I remove it from the config. then it will switch back to the local unbound server.

Then I add the quad9 server back to the config and pihole will continue to use the
local server for some time (days, usually) then revert to quad9.

I assume that pihole has some algorithm or service checking to decide which dns server to use
and I am (mostly) ok with that.

What I want to know is this:
Is there some logging setting so that I can a log message from pihole that says "switching to dns_2",
preferably with a reason like "dns_1 server not responding".

I have looked through the docs and I don't see one.

Details about my system:

I have the following in my setupVars.conf
PIHOLE_DNS_1=192.168.50.53
PIHOLE_DNS_2=9.9.9.10

the 192.168. addrs is a container running unbound
9.9.9.10 is, of course, a QUAD9, unfiltered, no DNSSEC server

2

This is not how DNS works.

There is no "backup". They are just 2 separate DNS servers.
When you set 2 servers, Pi-hole will use both of them.

3

Thank you for your reply.

My pihole instance will use my local unbound server exclusively, for days/weeks at a time.
it will then switch to quad9 and will use that one exclusively for days/weeks at a time.

This behavior appears to be not just "using both", but rather making a decision to switch servers;
either because one has timed out, or takes longer than some threshold to respond.

Since I have some experience working on/writing code for DNS servers/proxies/caches/clients,
I can explore the dnsmasq code/docs as well to see if I can figure out why it switches, but I was hoping for a helpful answer here first.

4

According to the docs here: DNS resolver - Pi-hole documentation

FTL will forward to the fastest server for a period of time:

Improve detection algorithm for determining the "best" forward destination
The DNS forward destination determination algorithm in FTLDNS's is modified to be much less restrictive than the original algorithm in dnsmasq. We keep using the fastest responding server now for 1000 queries or 10 minutes (whatever happens earlier) instead of 50 queries or 10 seconds (default values in dnsmasq). We keep the exceptions, i.e., we try all possible forward destinations if SERVFAIL or REFUSED is received or if a timeout occurs. Overall, this change has proven to greatly reduce the number of actually performed queries in typical Pi-hole environments. It may even be understood as being preferential in terms of privacy (as we send queries much less often to all servers). This has been implemented in commit d1c163e.

1 Like
5

I have pihole running on 2 machines here, both have local installs of unbound. When I add both unbounds to each configuration I find pihole tends to prefer to use unbound on the other machine. I assumed it was because at the point when pihole is handling a DNS request the other pihole would be dormant so faster.

6

rdwebdesign is correct in pointing out that DNS_2 is not defining a backup server.
So if you are using multiple DNS servers, it is expected that Pi-hole switches them around any time.

Pi-hole will use both of them as it sees fit, i.e. it would periodically send DNS requests to all configured upstreams and keep using the most reliable, fastest responding one.

As a recursive resolver, unbound is bound to be slower, except if it would have cached the domains in use when Pi-hole does its assessment. Once Quad9 wins the contest, it will be harder for unbound to win it back, as it won't have a chance to cache records from previous lookups if its not used.

So in your specific case, I'd expect unbound to be the least used upstream over time.

I would recommend using unbound as Pi-hole's sole upstream.

7

ok.
I will look at the changelog to see when this was done. It seems recent-ish.

I will grep my logs to see how often it switches.
Thank you

8

I should not have said "backup". I have a 2nd upstream server configured so that if my unbound instance dies, pihole can still resolve.

I originally had only the unbound instance in my config, but then the container it was running in got
wedged, which caused some problems.

It would be nice to be able to weight them so that pihole would prefer one over the other. (I prefer the unbound server for privacy reasons).

9

My opinion is that its best to have two Pi-hole instances/nodes running with Unbound upstream.
I currently at home can choose between running Pi-hole bare metal on a Raspberry Pi, containerized on my NAS, or on an old Intel NUC hypervisor in a VM.
Plenty to choose from :wink:

Below site has some interesting facts about the root servers Unbound uses to resolve TLD's:

As of 2024-02-07T01:25:34Z, the root server system consists of 1758 instances operated by the 12 independent root server operators.

The only dependency I have is my ISP uplink.

10

It is not recent. Several years at least.

11

The commit in the quoted text (d1c163e) is almost 6 years old: Improve on the parameters of dnsmasq's upstream selection algorithm · pi-hole/FTL@d1c163e · GitHub

12

If you are really sure this is what you want, switching to server 2 only if server 1 is non-responsive can easily be enabled through this option:

strict-order
By default, dnsmasq will send queries to any of the upstream servers it knows about and tries to favour servers that are known to be up. Setting this flag forces dnsmasq to try each query with each server strictly in the order they appear in /etc/resolv.conf

Sending the query to the second instead of the first upstream server is triggered by the client asking again after some time and Pi-hole then forwarding the same query to the other server (as the first did not respond). There is no mechanism that'd make your Pi-hole retry a query on its own behalf as the current implementation proved to work well in all known scenarios.

Pi-hole v5.x and earlier

Add

strict-order

to any custom file in /etc/dnsmasq.d, e.g. /etc/dnsmasq.d/99-custom-stuff.conf and restart pihole-FTL afterwards.

Pi-hole v6.0 and later

If you've already joined the beta of Pi-hole v6, simply enter this line on the All settings page under misc.dnsmasq_lines without having to edit any file on the system:

dnsmasq_lines

The subsequent restart will automatically be done for you.

1 Like
13

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