Open lbschenkel opened 1 month ago
The problem in your ISP routers, avoid hijacking DNS changed. Please extend with TP-Link router or Deco
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.
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.
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
Expected result
I have configured Adguard Home the following way:
1.2.3.4
(only accessible when a specific interface is up)https://mozilla.cloudflare-dns.com/dns-query
(or any other DoH with a TLS cert that only contains the hostname, not IP)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:https://mozilla.cloudflare-dns.com/dns-query
mozilla.cloudflare-dns.com
to do soActual result
DNS lookup fails after a long time.
In logs I only see the UDP failures of the upstream, but no evidence of the fallback being tried:
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 standalonednsproxy
works — but for some reason in Adguard it does not.