Problem where fallback DNS is being used

[Lucid1010]

You cannot view this attachment.

Code Select Expand

$ cat /etc/resolv.conf
# This file was automatically generated by system_resolvconf_generate()
# If you want to append configuration here use /etc/resolv.conf.local
domain xxxxxxxxxxxxxxxx
nameserver 192.168.1.1
nameserver 1.1.1.1
nameserver 1.0.0.1
search xxxxxxxxxxxxxxx

Code Select Expand

$ drill google.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 41425
;; flags: qr rd ra ; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; google.com.  IN      A

;; ANSWER SECTION:
google.com.     114     IN      A      xxxxxxx
xxx
;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 192.168.1.1

# --

$ drill google.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 13948
;; flags: qr rd ra ; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; google.com.  IN      A

;; ANSWER SECTION:
google.com.     281     IN      A       xxx
xxxx
;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 4 msec
;; SERVER: 1.1.1.1
I am currently using AdGuard Home as my main DNS server.
AdGuard Home responds immediately and works without issue.
However, whenever a DNS query is made, my device alternates between AdGuard Home (192.168.1.1) and Cloudflare DNS(1.1.1.1).

Is it possible to set it up so AdGuard Home is used as the sole primary DNS, 
and Cloudflare DNS is only used as a fallback when AdGuard Home is delayed or unresponsive?

[meyergru]

"drill" without any options explicitly randomizes the nameserver list. For the test you want, you must use "drill -z".

But that probably does not solve your actual issue. When OPNsense itself resolves a name using the servers from resolv.conf, they are normally tried in order, so you already have a kind of fallback there. The same is not guaranteed for DHCP clients to which you hand out a list of DNS servers.

The clients decide for themselves how to deal with a list of DNS servers, and that behavior differs between operating systems. Therefore, handing out AdGuard as DNS1 and Cloudflare as DNS2 does not reliably mean "use AdGuard unless it is unavailable".

If you want a real fallback for your clients, hand out only the address of a local resolver and implement the fallback there. For example, OPNsense's Dnsmasq has the option "Query DNS servers sequentially", which queries upstream DNS servers in the configured order.

Unbound with multiple forwarders would not provide strict primary/fallback ordering, as Unbound selects forwarders based on its own server-selection and RTT logic.

[bamf]

If you only need a fallback in case AdGuardHome is unavailable, better set up a second instance on another machine. You can use adguardhome-sync to synchronize your settings.

However, this will get you unreliable statistics as your clients will randomly pick one of your instances. I have solved that with keepalived. Set up a virtual IP for keepalived on both machines and use that IP address as your DNS server. If the main instance goes down, the virtual ip will move to the second machine and that instance will answer the queries.

[nero355]

However, whenever a DNS query is made, my device alternates between AdGuard Home (192.168.1.1) and Cloudflare DNS(1.1.1.1).

That's how DNS works for everyone and the whole Primary/Secondary DNS Server thing is basically a big fat lie : DNS does not work that way! ;)

If you want redundant DNS then you need to CARP/KeepAliveD the whole thing and for Pi-Hole there is a very easy solution now for a month or two or so : https://discourse.pi-hole.net/t/release-pi-hole-ha-automatic-dhcp-failover-vip-and-config-sync-for-a-pi-hole-cluster/86667
No more messing around with KeepAliveD scripts to achieve the same thing :)

[Patrick M. Hausen]

That's how DNS works for everyone and the whole Primary/Secondary DNS Server thing is basically a big fat lie : DNS does not work that way! ;)

That's also not quite correct. Primary/secondary is an attribute assigned to authoritative DNS servers. The primary for a zone is where the zone is maintained by whatever method. The secondary pulls zone updates from the primary.

It is true that at least in standard implementations up until now there is no order of precedence at the client side. The resolver library (the piece of software doing the lookups) uses all configured servers in round-robin fashion. That's why you do not necessarily need CARP but you need consistency of all your configured recursive servers.

E.g. 2 Active Directory domain controllers will always return the same data for your internal domain. That's a perfectly fine setup.

But one internal DC and 1.1.1.1 is nonsense because the latter has no knowledge of your internal domain. And they will both be used. There is no fallback concept in DNS clients.

[nero355]

That's also not quite correct. Primary/secondary is an attribute assigned to authoritative DNS servers. The primary for a zone is where the zone is maintained by whatever method. The secondary pulls zone updates from the primary.

That's a whole different story ofcourse :)

My target was this stuff :

It is true that at least in standard implementations up until now there is no order of precedence at the client side. The resolver library (the piece of software doing the lookups) uses all configured servers in round-robin fashion.
That's why you do not necessarily need CARP but you need consistency of all your configured recursive servers.

E.g. 2 Active Directory domain controllers will always return the same data for your internal domain. That's a perfectly fine setup.

But one internal DC and 1.1.1.1 is nonsense because the latter has no knowledge of your internal domain.
And they will both be used.

There is no fallback concept in DNS clients.

And I fully agree with you ;)