Fallback DNS servers never used

lbschenkel commented 1 month ago

Prerequisites

[X] I have checked the Wiki and Discussions and found no answer
[X] I have searched other issues and found no duplicates
[X] I want to report a bug and not ask a question or ask for help
[X] I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

Linux, ARMv7

Installation

Custom package (OpenWrt, HomeAssistant, etc; please mention in the description)

Setup

On a router, DHCP is handled by the router

AdGuard Home version

v0.107.46

Action

# dig example.com

Expected result

I have configured Adguard Home the following way:

Upstream DNS servers:
- 1.2.3.4 (only accessible when a specific interface is up)
Fallback DNS servers:
- https://mozilla.cloudflare-dns.com/dns-query (or any other DoH with a TLS cert that only contains the hostname, not IP)
Bootstrap DNS servers:
- https://1.1.1.1/dns-query
- https://8.8.8.8/dns-query
- https://9.9.9.9/dns-query
upstream_timeout: 3s (but happens with any timeout)

Therefore I expect, when 1.2.3.4 becomes unreachable:

Adguard falls back to the DNS server https://mozilla.cloudflare-dns.com/dns-query
Adguard needs to resolve mozilla.cloudflare-dns.com to do so
Adguard uses one of the boostrap DNS servers to resolve domain from step 2, that works since it's based on IP and TLS cert allows it
Adguard resolves the domain using DoH from step 1
The DNS query succeeds within a reasonable time

Actual result

DNS lookup fails after a long time.

# dig example.com
;; 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
;; communications error to ::1#53: timed out

; <<>> DiG 9.18.27 <<>> example.com
;; global options: +cmd
;; no servers could be reached

In logs I only see the UDP failures of the upstream, but no evidence of the fallback being tried:

[error] dnsproxy: upstream 1.2.3.4:53 failed to exchange ;example.com. IN       A in 6.019199946s: exchanging with 1.2.3.4:53 over udp: read udp <redacted>:50041->1.2.3.4:53: i/o timeout

Note that if I do the exact same setup in dnsproxy standalone, it does work as expected. I'm puzzled as to why the version embedded in Adguard works differently.

Additional information and/or screenshots

I have double checked the whole network setup, checked via dnslookup, and all the fallbacks and bootstrap servers are reachable. As I mentioned, the very same setup via standalone dnsproxy works — but for some reason in Adguard it does not.

riandoza commented 3 weeks ago

The problem in your ISP routers, avoid hijacking DNS changed. Please extend with TP-Link router or Deco

lbschenkel commented 3 weeks ago

The problem in your ISP routers, avoid hijacking DNS changed. Please extend with TP-Link router or Deco

Even if that was true, which is not, if you actually read the report you would have seen that the scenario described is when the single UDP upstream DNS server is unreachable and all the fallback / bootstrap ones use DoH and cannot be hijacked, only blocked — and they are not.

timkgh commented 2 weeks ago

How are fallback servers supposed to work anyway? Does AGH switch to them once it detects the main upstreams are down? Or does each query wait for the timeout (the default 10s is a lot) and then falls back for each query which would make DNS resolution pretty much unusable?

I found that the most reliable and fastest setup is to enable parallel requests to a couple of upstreams, though that's not an ideal setup if you want to prefer a private server and only use public servers if the private one is down.

AdguardTeam / AdGuardHome