Multiple Conditional Forwarders for the Same Domain

I mostly want to make sure I am setting this up correctly.

Expected Behaviour:

Add two conditional forwarders for redundancy. For example I have three piholes. Each with a version of these entries.

true,10.0.0.0/8,10.10.10.8,home.lan

true,10.0.0.0/8,10.10.10.9,home.lan

I have two windows server DNS servers with DHCP in sync for redundancy. I would like for the piholes to use either both, or one or the other depending on the first entry in the list and if it cannot contact one server it will contact the other.

Ubuntu Server 24.04.4 running on esxi.

Core v6.4.2

FTL v6.6.2

Web interface v6.5

Actual Behaviour:

The piholes seem to just use the first entry and nothing more even if that server is down.

Debug Token:

Nothing to debug.

Thats not what I observe on my sandbox VM with made up IP's and domain name (EDIT: hence the time out errors):

$ sudo pihole-FTL --config dns.revServers '["true,10.10.10.0/24,10.10.10.10,test.domain","true,10.10.10.0/24,10.10.10.20,test.domain"]'
[ true,10.10.10.0/24,10.10.10.10,test.domain, true,10.10.10.0/24,10.10.10.20,test.domain ]
$ dig +noall @localhost test.domain
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out
;; no servers could be reached
$ sudo pihole tail
[..]
18:33:33: query[A] test.domain from 127.0.0.1
18:33:33: forwarded test.domain to 10.10.10.10
18:33:33: forwarded test.domain to 10.10.10.20

I believe queries are distributed according to below logic "Improve detection algorithm ...":

If its not working for you, better upload a debug log and post the resulting token URL here for the mods/devs to inspect!

You are better off by using some kind of VRRP setup for your Pi-Holes instead of your current plan !!

There have been many topics about it already, but I have recently discovered this one : GitHub - SeimusS/Pihole-HA: Configuration of keepalived to create a HA cluster for Pihole with DNS and Unbound port tracking ยท GitHub
Give it a try! :wink:

I may have configured it wrong. I was having some local name resolution problems where the piholes were holding onto some old client names that were no longer correct. I made this thread to make sure if what I wanted it to do would work as I desired.

I'll have to look into it. At least for the two esxi hosted piholes for sure and then use the compute stick hosted one as the secondary for clients. I've seen a few different HA designs people have come up with however most of those involved some middleman instance that would be a single point of failure again. This one seems like it would work like a cluster and would allow instant failover takeover and high redundancy. I'd have to move some IPs around though since I quite like quad 10s as my primary DNS server IP.

Can you explain why a little?
Bc I'm a profound supporter of KISS!

I think you have see me explain it before, but 'special for you my friend' =>

DNS Time-outs :grimacing:

I have seen it happen a couple of times :

  • Client has DNS 1 and DNS 2 configured.
  • Something bad happens to DNS 1 or DNS 2.
  • Client starts experiencing weird delays and time-outs during simple internet browsing!

When using CARP/VRRP this should not happen AFAIK :wink:

I asked not only to educate me, but also the OP.
It was a bit weird/not complete to offer a suggestion but not explaining why.

I've had to perform maintenance on my two Pi-hole nodes a couple of times now, taking one down, and did not experience the issues you describe.
If its not necessary to add complexity, my opinion is dont do it ... KISS.

Plus that link of yours is an active-passive setup:

Meaning only one of your Pi-hole nodes is active processing queries while the other(s) do nothing.
I prefer my current active-active setup which spreads the load plus having redundancy.

While admining a couple of active-passive cluster for work, I've experienced the active node going down, and the passive standby node failing to come on-line for some reason ... causing the whole cluster to fail.
Same for hot-spare disks in a RAID setup.

'Different people, different experiences' then I guess...

Oh well... :slight_smile: