AdguardTeam / AdguardTeam/AdGuardHome
Fallback DNS servers never used
- Dominant language
- TypeScript
- Stars
- 36.9k
- Forks
- 2.5k
- PR merge metrics
- No merged PRs in 30d
Description
### Prerequisites
- [X] I have checked the [Wiki](https://github.com/AdguardTeam/AdGuardHome/wiki) and [Discussions](https://github.com/AdguardTeam/AdGuardHome/discussions/categories/q-a) 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](https://github.com/AdguardTeam/AdGuardHome/discussions/categories/q-a)
- [X] I have set up AdGuard Home correctly and [configured clients to use it](https://github.com/AdguardTeam/AdGuardHome/wiki/Clients). (Use the [Discussions](https://github.com/AdguardTeam/AdGuardHome/discussions/categories/q-a) 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
```sh
# 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:
1. Adguard falls back to the DNS server `https://mozilla.cloudflare-dns.com/dns-query`
2. Adguard needs to resolve `mozilla.cloudflare-dns.com` to do so
3. 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
4. Adguard resolves the domain using DoH from step 1
5. 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 :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.
Contributor guide
Assessment
This issue has not been assessed yet.