Specific domain upstream DNS no longer working after update

RoboMagus commented 1 year 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

Operating system type

Linux, Other (please mention the version in the description)

CPU architecture

64-bit ARM

Installation

Docker

Setup

On a router, DHCP is handled by the router

AdGuard Home version

v0.107.31

Description

What did you do?

Auto update the docker container.

Expected result

Local / specific domain resolution to continue working.

Actual result

Name resolution broken

Screenshots (if applicable)

-

Additional information

I have configured specific domain resolution according to the documentation for upstream DNS as follows:

...
[/local/home/*]udp://mdns-bridge
...

Here mdns-bridge is a docker service running side-by-side with adguard home that queries mdns.

Prior to the latest update this has worked fine for months, but now this no longer works. Name resolution fails:

; <<>> DiG 9.18.13 <<>> @192.168.1.26 esp32-meterkast.home
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 13418
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;esp32-meterkast.home.          IN      A

;; Query time: 0 msec
;; SERVER: 192.168.1.26#53(192.168.1.26) (UDP)
;; WHEN: Sat Jun 10 08:08:57 UTC 2023
;; MSG SIZE  rcvd: 38

On v0.107.29 it succeeds:

; <<>> DiG 9.18.13 <<>> @192.168.1.26 esp32-meterkast.home
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40733
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;esp32-meterkast.home.          IN      A

;; ANSWER SECTION:
esp32-meterkast.home.   3600    IN      A       192.168.1.92

;; Query time: 15 msec
;; SERVER: 192.168.1.26#53(192.168.1.26) (UDP)
;; WHEN: Sat Jun 10 08:15:41 UTC 2023
;; MSG SIZE  rcvd: 65

PeterDaveHello commented 1 year ago

I got similar(or just the same) situation.

RoboMagus commented 1 year ago

Looking at some verbose logging it seems something is failing in the dialExchange function in upstream_plain of the Adguard DnsProxy.

Logs on v0.107.31 (Failing):

2023/06/10 16:01:48.824292 7#289 [debug] dnsproxy: handling new udp packet from 192.168.1.77:55619
2023/06/10 16:01:48.824444 7#289 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): IN: ;; opcode: QUERY, status: NOERROR, id: 4
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;esp32-meterkast.home. IN       A

2023/06/10 16:01:48.824618 7#289 [debug] applying filters: looking for client with ip 192.168.1.77 and clientid ""
2023/06/10 16:01:48.824710 7#289 [debug] applying filters: using settings for client "Legion" (192.168.1.77; "")
2023/06/10 16:01:48.825170 7#289 [debug] applying filters: services for client "Legion" set: []
2023/06/10 16:01:48.825281 7#289 [debug] hosts container: handling the request for esp32-meterkast.home
2023/06/10 16:01:48.825878 7#289 [debug] safe browsing: found "esp32-meterkast.home" in cache, blocked: false
2023/06/10 16:01:48.826031 7#289 [debug] github.com/AdguardTeam/AdGuardHome/internal/filtering.(*DNSFilter).checkSafeBrowsing(): safebrowsing lookup for "esp32-meterkast.home"; Elapsed time: 0ms
2023/06/10 16:01:48.826532 7#289 [debug] mdns-bridge:53: sending request over udp: A esp32-meterkast.home.
2023/06/10 16:01:48.826681 7#289 [debug] mdns-bridge:53: response received over udp: dialing mdns-bridge:53 over udp: no addresses
2023/06/10 16:01:48.827049 7#289 [debug] upstream mdns-bridge:53 failed to exchange ;esp32-meterkast.home.     IN       A in 279.644µs: dialing mdns-bridge:53 over udp: no addresses
2023/06/10 16:01:48.827164 7#289 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).replyFromUpstream(): RTT: 1.002468ms
2023/06/10 16:01:48.827704 7#289 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): OUT: ;; opcode: QUERY, status: SERVFAIL, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;esp32-meterkast.home. IN       A

Whereas in v0.107.29 it succeeds:

2023/06/10 16:15:51.160877 7#531 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).udpHandlePacket(): Start handling new UDP packet from 192.168.1.77:54846
2023/06/10 16:15:51.161063 7#531 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): IN: ;; opcode: QUERY, status: NOERROR, id: 2
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;esp32-meterkast.home. IN       A

2023/06/10 16:15:51.161245 7#531 [debug] applying filters: looking for client with ip 192.168.1.77 and clientid ""
2023/06/10 16:15:51.161363 7#531 [debug] applying filters: using settings for client "Legion" (192.168.1.77; "")
2023/06/10 16:15:51.161504 7#531 [debug] applying filters: services for client "Legion" set: []
2023/06/10 16:15:51.161651 7#531 [debug] hosts container: handling the request for esp32-meterkast.home
2023/06/10 16:15:51.165537 7#531 [debug] github.com/AdguardTeam/AdGuardHome/internal/filtering.check(): SafeBrowsing: checking esp32-meterkast.home: 6524.25bf.sb.dns.adguard.com.
2023/06/10 16:15:51.165743 7#531 [debug] https://family.adguard-dns.com:443/dns-query: sending request TXT 6524.25bf.sb.dns.adguard.com.
2023/06/10 16:15:51.174756 7#531 [debug] https://family.adguard-dns.com:443/dns-query: response: ok
2023/06/10 16:15:51.174939 7#531 [debug] SafeBrowsing: received hashes for esp32-meterkast.home: [652452e51c0f9cfdf922bfa86ee898f799b05c962f934ede881b05a305605877 25bfd8b6b4e9bd1a3448aadc784fc3fc32be128c4>
2023/06/10 16:15:51.175106 7#531 [debug] SafeBrowsing: stored in cache: [37 191]
2023/06/10 16:15:51.175213 7#531 [debug] SafeBrowsing: stored in cache: [101 36]
2023/06/10 16:15:51.175381 7#531 [debug] github.com/AdguardTeam/AdGuardHome/internal/filtering.(*DNSFilter).checkSafeBrowsing(): safebrowsing lookup for "esp32-meterkast.home"; Elapsed time: 9ms
2023/06/10 16:15:51.175562 7#531 [debug] mdns-bridge:53: sending request A esp32-meterkast.home.
2023/06/10 16:15:51.443847 7#531 [debug] mdns-bridge:53: response: ok
2023/06/10 16:15:51.444286 7#531 [debug] github.com/AdguardTeam/dnsproxy/upstream.exchange(): upstream mdns-bridge:53 successfully finished exchange of ;esp32-meterkast.home. IN       A. Elapsed 268.47772>
2023/06/10 16:15:51.444696 7#531 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).replyFromUpstream(): RTT: 268.895297ms
2023/06/10 16:15:51.445074 7#531 [debug] dnsforward: checking A 192.168.1.92 for esp32-meterkast.home.
2023/06/10 16:15:51.449106 7#531 [debug] client ip: 192.168.1.77
2023/06/10 16:15:51.449585 7#531 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): OUT: ;; opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;esp32-meterkast.home. IN       A

;; ANSWER SECTION:
esp32-meterkast.home.  3600    IN      A       192.168.1.92

RoboMagus commented 1 year ago

Managed to fix my issue!

Since dnsproxy v0.49.1 upstreams defined by a hostname are bootstrapped using the bootstrap dns entries. Adding my local dns (docker container names) resolver to the bootstrap list solves the issue for me.

Would've been nice to see this Breaking Change listed in the release notes though...

PeterDaveHello commented 1 year ago

Maybe leave it opened for further improvement?

RoboMagus commented 1 year ago

@PeterDaveHello The specific symptoms described are solved by the mentioned solution. If that does not solve your issue it's probably best to open a new ticket describing exactly what it is that's causing issues on your end.

AdguardTeam / AdGuardHome