Hello, The issue I am facing:
I want to setup my EdgeRouter 10X to play a role as a Keep Alive server where it will check the two pi-hole availability and prioritize the one in docker, with full sync between them as databases and long term stat/graph data.
Details about my system:
I have pi-hole installed on Raspberry pi 1 and it is my primary DNS and it is working.
I recently set up a second pi-hole inside of a docker container on my new debian server.
I have set up my EdgeRouter 10X a NAT rule to forward all traffic on port 53 to pi-hole.
What I have changed since installing Pi-hole:
Installed second pi-hole into a docker container.
Most systems that allow multiple DNS servers to be defined will go after the DNS server based on the listing order as delivered by DHCP or defined in the resolver.conf file if Linux, or the adapter binding order if defined in Windows networking.
I also run two PiHoles and the one I have in a docker container on my NAS is the first server being call almost every time. The secondary one is on a Raspberry Pi 4 in a container and only gets called on rare times.
I did not need to do any type of router forwarding rules except for DNS capture to keep the IoT devices that hard code 8.8.8.8. That is a single point of failure of that DNS is down. In this case unless you are are using a F5 or other network load balancer that supports DNS round robin there isn't much other than writing to the API of your router and turning rules on and off based on pings or other health check options.
That's actually not true. You can not depend on any order for DNS servers. If multiple DNS servers are configured then you can pretty much guaranty that all will be used. If you don't declare "strict order" then each OS will use it's pre-designed method of round robin or weighted round robin choice.
Yes it depends on the configuration of the client but the default behavior for Linux clients are strict order unless you specify. In my home lab I have done multiple tests of this and they always goes in the order as I listed them on the resolve.conf
As for Windows this is a little more complex but if you define them per adapter bind the bind priority determines the resolver that will be used and it's "usually" sequential to the network config.
If you want real control than a VIP is needed along with a load balancing model that enforces strict order irrespective of client. At work we use the Anycast model for geographic location each location then has a VIP that has 4 dns servers behind that IP. We also use DNS capturing to cover rogue DNS lookup's that try to bypass our internal servers. Seems to work well for 80k worker endpoints.
Thats roughly 80% resolved through the "primary" and 20% by the "secondary".
I did not configure anything related to DNS forwarding order on the clients.
This is a reoccurring topic:
@Peterkal2112, have you searched Discourse here for what your looking?
Much has been discussed already and some bits are harder to implement as others.
Like syncing the long term dbase pihole-FTL.db live or scheduled which to my knowledge (???) is still not possible because of dbase tables getting locked all the time by the pihole-FTL daemon preventing any sync attempts to write.
pi@ph5a:~ $ ls -1 /etc/pihole/*.db
/etc/pihole/gravity.db
/etc/pihole/macvendor.db
/etc/pihole/pihole-FTL.db
I discovered gravity sync which is kind of a way to sync two pi-holes...
But my problem is somewhere else... I want to make a redundancy of two pi-holes...
One pi-hole as a primary and second pi-hole as a secondary and I want my EdgeRouter 10X to switch my NAT redirection of a port 53 to secondary pi-hole when the primary is down.
Can this be achieved somehow by some script ??? I discovered something like keepalived but i not really understand how it should work...
This is outside of Pi-hole's scope, nor can it be addressed by DNS means.
It's essentially a networking issue.
You may increase your chances for an answer by consulting Ubiquiti's forums for assistance in configuring conditional port forwarding rules, or network forums specialising in IP address fail-over solutions using CARP or VRRP protocl implementations.
