AdguardTeam
Fallback DNS servers never used
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.comto 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.
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.
I've the same problem. The fallback is never used when the main upstream server is offline or not responding. In the log I have
2024/11/14 16:05:49.467812 ERROR response received addr=quic://nottherealserveraddress.org:4000 proto=udp status="reading response from quic://nottherealserveraddress.org:4000: deadline exceeded" 2024/11/14 16:05:49.467862 ERROR response received addr=quic://nottherealserveraddress.org:4000 proto=udp status="reading response from quic://nottherealserveraddress.org:4000: deadline exceeded" 2024/11/14 16:05:54.491823 ERROR response received addr=quic://nottherealserveraddress.org:4000 proto=udp status="reading response from quic://nottherealserveraddress.org:4000: timeout: no recent network activity" 2024/11/14 16:05:54.491867 ERROR response received addr=quic://nottherealserveraddress.org:4000 proto=udp status="reading response from quic://nottherealserveraddress.org:4000: timeout: no recent network activity" 2024/11/14 16:05:54.491914 ERROR response received addr=quic://nottherealserveraddress.org:4000 proto=udp status="reading response from quic://nottherealserveraddress.org:4000: timeout: no recent network activity" 2024/11/14 16:05:54.491941 ERROR response received addr=quic://nottherealserveraddress.org:4000 proto=udp status="reading response from quic://nottherealserveraddress.org:4000: timeout: no recent network activity" 2024/11/14 16:05:54.492017 [error] dnsproxy: exchange failed upstream=quic://nottherealserveraddress.org:4000 question=";847112ae-ee63-4631-af5c-7e5bc4e749a9.test.dnsleaktest.com.\tIN\t HTTPS" duration=13.747748436s err="reading response from quic://nottherealserveraddress.org:4000: timeout: no recent network activity" 2024/11/14 16:05:54.491845 ERROR response received addr=quic://nottherealserveraddress.org:4000 proto=udp status="reading response from quic://nottherealserveraddress.org:4000: timeout: no recent network activity" 2024/11/14 16:05:54.491941 ERROR response received addr=quic://nottherealserveraddress.org:4000 proto=udp status="reading response from quic://nottherealserveraddress.org:4000: timeout: no recent network activity" 2024/11/14 16:05:54.491848 ERROR response received addr=quic://nottherealserveraddress.org:4000 proto=udp status="reading response from quic://nottherealserveraddress.org:4000: timeout: no recent network activity" 2024/11/14 16:05:54.491883 ERROR response received addr=quic://nottherealserveraddress.org:4000 proto=udp status="reading response from quic://nottherealserveraddress.org:4000: timeout: no recent network activity" 2024/11/14 16:05:54.491898 ERROR response received addr=quic://nottherealserveraddress.org:4000 proto=udp status="reading response from quic://nottherealserveraddress.org:4000: timeout: no recent network activity" 2024/11/14 16:05:54.491899 ERROR response received addr=quic://nottherealserveraddress.org:4000 proto=udp status="reading response from quic://nottherealserveraddress.org:4000: timeout: no recent network activity" 2024/11/14 16:05:54.491911 ERROR response received addr=quic://nottherealserveraddress.org:4000 proto=udp status="reading response from quic://nottherealserveraddress.org:4000: timeout: no recent network activity" 2024/11/14 16:06:04.494937 [error] dnsproxy: exchange failed upstream=quic://nottherealserveraddress.org:4000 question=";fb2f8a61-5439-4e19-b6b9-73b486dabb6c.test.dnsleaktest.com.\tIN\t HTTPS" duration=13.648081004s err="getting new conn: dialing quic connection to quic://nottherealserveraddress.org:4000: timeout: no recent network activity"
But, adguard home doesn't switch to the fallback server, it just died until the primary upstream server is up again.
Same issue here, fallback DNS does not seem to do anything. I just receive logs like this while DNS queries on the clients timeout:
2025/06/14 10:12:03.482779 [error] dnsproxy: exchange failed upstream=192.168.1.1:53053 question:";dns0.eu.\tIN\t A" duration=20.001683621s err="exchanging with 192.168.1.1:53053 over udp: read udp 192.168.2.1:53796->192.168.1.1:53053: i/o timeout"
