Issue with DNS over TLS upstream with v0.108.0

[Gandulf78]

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.

Version of AdGuard Home server:
v0.108.0-b.9
How did you install AdGuard Home:
docker
How did you setup DNS configuration:
N/A
If it's a router or IoT, please write device model:
WDMycloudEX2Ultra
CPU architecture:
ARMv7
Operating system and version:
Docker 20.10.15

Expected behaviour
DNS over TLS is working fine.

Current behaviour
Since at least v0.108.0-b.7 (now in v0.108.0-b.9), I have some trouble with DNS over TLS.
I cannot set DNS to tls://family-filter-dns.cleanbrowsing.org: the test upstream fails after 15 seconds and I receive the message "Server "tls://family-filter-dns.cleanbrowsing.org": could not be used, please check that you've written it correctly"
In the logs : 2022/06/10 08:01:19.125844 [info] upstream "tls://family-filter-dns.cleanbrowsing.org" fails to exchange: couldn't communicate with upstream: getting connection to tls://family-filter-dns.cleanbrowsing.org:853: connecting to family-filter-dns.cleanbrowsing.org: all dialers failed: dial tcp 185.228.168.168:853: i/o timeout

With tls://dns-family.adguard.com, the test takes 30s and finally succeeds.
DNS setting to quic://dns-family.adguard.com is working fine and DOH with https://doh.cleanbrowsing.org/doh/family-filter/ too so the issue seems to be restricted to DOT.
I am running AGH on ARMv7 plateform with docker 20.10.15.

docker run --name adguardhome
--restart always
-v CaddyVolume:/opt/adguardhome/work
-v adguard-conf:/opt/adguardhome/conf
-p 53:53/tcp -p 53:53/udp
-p 67:67/udp -p 68:68/udp
-p 80:80/tcp -p 443:443/tcp -p 443:443/udp -p 3000:3000/tcp
--net home --ip 10.0.0.21
-d adguard/adguardhome:v0.108.0-b.9

[emlimap]

connecting to family-filter-dns.cleanbrowsing.org: all dialers failed: dial tcp 185.228.168.168:853: i/o timeout

That error sounds like something is blocking access to port 853. It could be the firewall on your router or your ISP or something else in between you & clean browsing servers.

As a test you can try any of the below DNS servers to see if they are working just to rule out this issue is/isn't isolated to cleanbrowsing DNS alone.

tls://dns.adguard.com
tls://security.cloudflare-dns.com
tls://dns.quad9.net
tls://dns.google

[Gandulf78]

Ok so I tested these 4 TLS servers.
After 30s for each of them the test succeed (when it is instantaneous for quic or dns over https). I can set up these TLS servers as DNS upstream. Then I tested the performance : the mean duration to get a DNS resolution is 20s! (Around 20ms with quic or DOH).
In comparison, DNS over TLS used to be quicker than DOH on Adguard Home with v0.107 so for me there's an issue.
I have also tested unbound-rpi on the same Docker with cleanbrowsing in DOT and it is working perfectly fine with port 853 (it worked with AGH 0.107 too) so I don't think the issue is with my firewall.

[emlimap]

Personally I can't reproduce this issue on my 0.108-b9 install. I have a mixture of DoH, DoT & Quic upstream sources and the test button takes no longer than a few seconds.

At this point, developers would probably want to see the verbose log to further diagnose this issue.

1. Enable verbose by following this guide https://github.com/AdguardTeam/AdGuardHome/wiki/FAQ#verboselog
2. Add your DoT sources and do a test like you did before, both clean browsing which fails and DoT resolvers that take 30 seconds to pass the test.
3. Save the file once you have completed the above step and attach the file to this issue. If you feel that the data might contain sensitive information, you can also email them to the address mentioned in Adguard's organization page https://github.com/AdguardTeam. I would suggest including product name(AdGuard Home) & issue number 4655 in the subject to make it easier for them to identify.

If you have access to another ISP, either via tethering your mobile temporarily or using a VPN to test if the issue still occurs. This way you can rule out any ISP routing/blocking/misconfiguration problems.

[Gandulf78]

OK thanks. I have recorded and sent logs by email to the team.

[diasdmhub]

My open discussion #6802 seems to be related to this issue.