Can not query IPv6 upstream occasionally

[Mosney]

Have a question or an idea? Please search it on our forum to make sure it was not yet asked. If you cannot find what you had in mind, please submit it here.

Prerequisites

Please answer the following questions for yourself before submitting an issue. YOU MAY DELETE THE PREREQUISITES SECTION.

• I am running the latest version
• I checked the documentation and found no answer
• I checked to make sure that this issue has not already been filed

Issue Details

• Version of AdGuard Home server:
  v0.105.2
• How did you install AdGuard Home:
  Github releases
• How did you setup DNS configuration:
  Router
• If it's a router or IoT, please write device model:
  amd64 device
• CPU architecture:
  AMD64
• Operating system and version:
  OpenWrt19.07

Expected Behavior

Query IPv6 upstream as before

Actual Behavior

Cannot query IPv6 upsteam like IPv4

Screenshots

Client Setting:

NextDNS log:

Query on OpenWrt ditectly:

listening addresses(contain IPv6 address):

Additional Information

I want audit a device, so I specified extra IPv6 upstream from NextDNS to this device in April 1. And now I find NextDNS lack of recent log, so I check on AdGuardHome found it cannot query IPv6 upsteam for now, the first 2 days looks good, but today and yesterday totally cannot. I change client upstream setting only left IPv6, not work anymore. I also test query on OpenWrt directly via kdig and result looks good, so I don't know why AdGuardHome cannot query (even I restart AGH and reboot OpenWrt), I run AGH bin file from github release as init.d services on OpenWrt directly.
Give ip a info for check:

9: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether a0:XX:XX:XX:XX:a0 brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.1/24 brd 10.1.1.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 2408:XXXX:XXXX:62f0::1/60 scope global dynamic 
       valid_lft 257169sec preferred_lft 170769sec
    inet6 fd88::1/60 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::XXXX:XXXX:XXXX:34a0/64 scope link 
       valid_lft forever preferred_lft forever

16: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN qlen 3
    link/ppp 
    inet 27.X.X.113 peer 27.X.X.1/32 scope global pppoe-wan
       valid_lft forever preferred_lft forever
    inet6 2408:XXXX:XXXX:XXXX:b040:6766:486f:98dc/64 scope global dynamic 
       valid_lft 258654sec preferred_lft 172254sec
    inet6 fe80::XXXX:XXXX:XXXX:98dc/10 scope link 
       valid_lft forever preferred_lft forever

[ainar-g]

Hi, your configuration for the client seems to be wrong: in addresses with IPv6 the address must be in square brackets:

tls://[a:b:c::d]:853

Otherwise, the parser doesn't really know where the IPv6 address ends and where the port start. Can you try adding the brackets and report if that fixes the issue?

[Mosney]

Thanks for your help, but not about the brackets, and it's truely remind me why I first add IPv6 upstream without port cannot continue. Back to the issue mentioned above, my config indeed not total correct, but it work for a while(see NextDNS April 1 log). After your notice,I correct my config to tls://[2a07:a8c0::2b:afca]:853 tls://[2a07:a8c1::2b:afca]:853 and watch for 6 hours until now, NextDNS still have no new logs, it means AdGuardHome still cannot query by those IPv6 upstream.

[Mosney]

I creat a new AdGuardHome instance and enable verbose log, looks cause tls cert verify fail, NextDNS's cert not cotain their IPv6 address.
Log list below, please check.
May AdGuardHome could add some feature about cert validate configuration? Such as [-tls-host-verify]: TLS cert hostname to verify. [-no-check-certificate]: No check certificate. From this https://github.com/pymumu/smartdns/blob/master/ReadMe_en.md#configuration-parameter server-tls section.

---

Key log:

2021/04/06 04:06:21 12828#38 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).udpHandlePacket(): error handling DNS (udp) request: talking to dnsUpstream failed, cause: all upstreams failed to respond, cause: Failed to get a connection from TLSPool to tls://[2a07:a8c0::2b:afca]:853, cause: Failed to connect to 2a07:a8c0::2b:afca, cause: x509: cannot validate certificate for 2a07:a8c0::2b:afca because it doesn't contain any IP SANs (hidden: Failed to get a connection from TLSPool to tls://[2a07:a8c1::2b:afca]:853, cause: Failed to connect to 2a07:a8c1::2b:afca, cause: x509: cannot validate certificate for 2a07:a8c1::2b:afca because it doesn't contain any IP SANs)

Full log:

2021/04/06 04:06:20 12828#38 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).udpHandlePacket(): Start handling new UDP packet from 10.1.1.20:49922
2021/04/06 04:06:20 12828#38 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): IN: ;; opcode: QUERY, status: NOERROR, id: 37332
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;g.co.	IN	 A

;; ADDITIONAL SECTION:

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: ; udp: 4096
; COOKIE: 9124f5d3d779b82f

2021/04/06 04:06:20 12828#38 [debug] AutoHosts: answer: g.co -> []
2021/04/06 04:06:20 12828#40 [debug] github.com/AdguardTeam/dnsproxy/upstream.(*bootstrapper).createDialContext.func1(): Dialing to [2a07:a8c1::2b:afca]:853
2021/04/06 04:06:20 12828#39 [debug] github.com/AdguardTeam/dnsproxy/upstream.(*bootstrapper).createDialContext.func1(): Dialing to [2a07:a8c0::2b:afca]:853
2021/04/06 04:06:20 12828#39 [debug] github.com/AdguardTeam/dnsproxy/upstream.(*bootstrapper).createDialContext.func1(): dialer has successfully initialized connection to [2a07:a8c0::2b:afca]:853 in 154 milliseconds
2021/04/06 04:06:21 12828#40 [debug] github.com/AdguardTeam/dnsproxy/upstream.(*bootstrapper).createDialContext.func1(): dialer has successfully initialized connection to [2a07:a8c1::2b:afca]:853 in 1255 milliseconds
2021/04/06 04:06:21 12828#38 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).Resolve(): RTT: 1754 ms
2021/04/06 04:06:21 12828#38 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): OUT: ;; opcode: QUERY, status: SERVFAIL, id: 37332
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;g.co.	IN	 A

2021/04/06 04:06:21 12828#38 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).udpHandlePacket(): error handling DNS (udp) request: talking to dnsUpstream failed, cause: all upstreams failed to respond, cause: Failed to get a connection from TLSPool to tls://[2a07:a8c0::2b:afca]:853, cause: Failed to connect to 2a07:a8c0::2b:afca, cause: x509: cannot validate certificate for 2a07:a8c0::2b:afca because it doesn't contain any IP SANs (hidden: Failed to get a connection from TLSPool to tls://[2a07:a8c1::2b:afca]:853, cause: Failed to connect to 2a07:a8c1::2b:afca, cause: x509: cannot validate certificate for 2a07:a8c1::2b:afca because it doesn't contain any IP SANs)

[ainar-g]

I think I get it, thanks.

@ameshkov, do we want to allow skipping TLS checks on per-upstream basis? If so, in which timeframe?

[ameshkov]

Hm, tbh I don't really like it.

@Mosney if you really-really need this, consider running a dnsproxy instance that is started with --insecure flag and then configure AdGuard Home to use that instance.

[Mosney]

@ameshkov All right, I got it. I'll go ask NextDNS add their IP to cert SANs. Additionally, I want to say, the feature I want is not --insecure, it's can bee set to point hostname manually. Actually, I already use those tricks on SmartDNS which created by an Chinese dev, you know, local dev know authorities block (aka GFW) method and people's needs more. 😄️

[ameshkov]

Ah, I got the idea. Basically, you'd like to avoid sending the hostname in SNI, but continue to verify the hostname. Honestly, rather rare use case than --insecure, but I can understand why you need it.

[Mosney]

Yep, you got me, not everyone know GFW will block by SNI, it's hard to explain sometimes.