192.168.23.6 is my selfhosted AdGuard Home. THis works fine. I also added Quad 9 as an DNS-Server for fallback.
I thought this setting would set the AdGuard Home as default DNS for all clients, in case the AdGuard Home isn’t responsing, all clients get the Quad9 DNS.
But if i leave the settings like this, some clients use Quad9 as DNS and some clients use “both”, but filtering and blocking doesn’t work.
What is the mistake here? I just want all clients do use AdGuard Home and if the DNS is not reachable they should use Quad9.
Any time you advertise multiple DNS servers, they must return the same answer to all queries. The proper way to handle an asymmetric case like this is to have Quad9 strictly upstream from AGH. Only advertise Quad9 directly (e.g. via DHCP) when AGH goes down and cannot be fixed quickly.
If you feel the need for redundancy, set up two AGH servers on the LAN, one either cloning the other’s configuration or set up as a “slave” of the other.
I have had the same setup as you have, with Pi-hole, and didn’t understand why it was “so wild”. Now I have set up Pi-hole as my only DNS and it works just fine. But as you say, I have lost the fallback. In my case, it is not a problem since I am the quasi-sole user of my network, but in the case of a family it might be usefull to have a fallback. Maybe you can set up a different app (Pi-hole), so if a problem occurs with the app, you still have the fallback.
It is correct, sending multiple DNS server addresses to a client does NOT imply a priority. That is not a RouterOS thing, that is just general DNS and DHCP.
Also, even IF it would imply a priority, it is still true what @tangent wrote: the services must always return the same data or unreliable results will occur. E.g. some people my send the local RouterOS DNS and some local Pihole or whatever, and they have defined static DNS records there for their own services or to “mask” addresses for records served by upstream, and then they add a direct resolver to their clients. That does NOT work correctly.
When you need a fallback, you need to provide it at another level, not via DHCP. It would be possible to use some route and dst-nat tricks, for example.
Ah okay thanks for the replies guys. Now i understand.
I guess i dont really need a fallback, but in some cases i have to shutdown the AdGuard Home Container on my NAS or my NAS itself. I thought in this case there would be an easier way to switch to another DNS-server than to login to MikroTik-Router, changing DNS and force every device to use the new one. And after my NAS is running again, switching DNS-server back.
But okay, at least i got an answer to my question. Thank you!
Yes, that is what I mean with “use some route and dst-nat tricks”. You could setup some routes with different distance, the lowest with a ping-check, and when your NAS is off the next route would be used. That route could be setup such that a dst-nat becomes active, and the IP address of your AdGuard Home container is now translated to 9.9.9.9. Then it will failover automatically without causing problems while the container is running.
On my home router I use DSTNAT. All the DHCP network settings still advertise the router's local IP address on each subnet as DNS server (for example 192.168.88.1 for 192.168.88.0/24). All IPv6 -> ND entries advertise the router's single ULA address (assigned to a one of the interfaces, even lo works) as DNS server. IP ->DNS on the router is also setup correctly (with DoH).
(Unbound is on a bridge that is not part of the VLAN interface list, and my unbound even uses the router as upstream for local domains (such as .lan) lookup, so that I can still use RouterOS to manage the static local assignments)
Netwatch can then be used to automatically disable/enable the NAT rules with the "redirect to unbound" comment on the fly and in case the unbound host is down, the router will quickly take over as DNS resolver. On the clients, no setting changes are needed. Because the DHCP setting stays the same, the clients don't need to renew to get the new DNS setting from DHCP.
