Custom encrypted DNS upstream servers configured for a client are 4-5 times slower

[hagezi]

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, ARM64

Installation

GitHub releases or script from README

Setup

On a router, DHCP is handled by the router

AdGuard Home version

v0.108.0-b.66

Action

If custom encrypted DNS servers are configured for a client, the resolution times for this client are 4-5 times higher than the same standard configured encrypted DNS servers. If legacy DNS via IP is used instead, the problem does not occur.

Settings > Client Settings > Add/Edit Client Tab Upstream DNS servers > Configure encrypted DoT or DoH Servers for the Client > Save > Test

Expected result

Same resolution times as with the standard configured encrypted upstream DNS servers.

Actual result

Resolution times are 4-5 times higher than the same standard configured encrypted DNS servers.

Additional information and/or screenshots

No response

[bohtho]

I have the same observation and problem with lag (actually 50-100 times more lag than standard encrypted requests) in v0.108.0-b.68 and edge as of today (v0.108.0-a.1088+61a1403e), and I think it may be related to this issue, because that's the error I also get in my syslog. But as OP reports it seems to only affect configured persistent clients with custom upstreams, as per the response times visible in the query log (disregarding cached responses).

So as I layman I would suggest there is something in the code for the persistent clients´ custom upstreams that handles quic (and encrypted dns requests) different from the standard upstreams.

[fbernier]

I may have a fix for this but it's still unconfirmed. Please give it a try if you'd like: https://github.com/AdguardTeam/AdGuardHome/pull/7789

[tjharman]

Thanks @fbernier I'll make the team aware of this.

[bohtho]

I may have a fix for this but it's still unconfirmed. Please give it a try if you'd like: https://github.com/AdguardTeam/AdGuardHome/pull/7789

I run adguard home with a certain complicated installer on my router so I think I have to wait for it to get merged into edge unfortunately...

[fbernier]

I may have a fix for this but it's still unconfirmed. Please give it a try if you'd like: #7789

I run adguard home with a certain complicated installer on my router so I think I have to wait for it to get merged into edge unfortunately...

I thought it would be a hassle too but turns out that cloning the repo on a linux desktop, running a single command to cross-compile to a single arm64 binary (make GOOS='linux' GOARCH='arm64'), scp-ing it to my router,docker cp` it to my docker container and restarting the container was pretty quick.

Here's an arm64 binary in case anyone's interested: https://drive.google.com/file/d/1NeGDB0tyX6A523Cp0GHC-M-Mqjturwcj/view

[bohtho]

I may have a fix for this but it's still unconfirmed. Please give it a try if you'd like: #7789

I run adguard home with a certain complicated installer on my router so I think I have to wait for it to get merged into edge unfortunately...

I thought it would be a hassle too but turns out that cloning the repo on a linux desktop, running a single command to cross-compile to a single arm64 binary (make GOOS='linux' GOARCH='arm64'), scp-ing it to my router,docker cp` it to my docker container and restarting the container was pretty quick.

Here's an arm64 binary in case anyone's interested: https://drive.google.com/file/d/1NeGDB0tyX6A523Cp0GHC-M-Mqjturwcj/view

Thanks, but my router uses armv7 architecture for most binaries, so it would really be much quicker and easier if maintainers would just merge this one-liner PR, which also actually fixes something that made the persistent client part of agh quite unusable since forever.

[hagezi]

ping @ainar-g

[tjharman]

I've made the AGH team aware of this already - no need to @ people.

[ainar-g]

Thanks for reporting! We've found that bug as well, and we're aiming to fix it in the next beta. Assigning to @schzhn, who is currently working on the fix.

[schzhn]

The fix is already in the edge release. You can download the binary for your platform from this page.

[bohtho]

Did the fix for this in edge somehow negate the fix for the custom caches that was just merged days ago...?

[ainar-g]

@bohtho, I'm not sure what you mean. Do you see any issues on the edge channel currently?

[hagezi]

Docker edge version v0.108.0-a.1089+2c46bc92 fixes the problem for me and the custom client cache also seems to work.

[ainar-g]

@bohtho, I cannot reproduce that on the current edge release. There is a separate issue where disabling the global cache also disables custom caches, and we're working on that at the moment, and it should be fixed by the next beta release.

[bohtho]

Leaving the global and custom caches at the same level (and turned on) the custom persistent clients definitely misses a lot in the cache even after several days. But suddenly some things are taken from cache too so I can't figure it out or pin it down.

Same edge v0.108.0-a.1089+2c46bc92

[bohtho]

Anyone else still seeing that the custom client caches are not working (perhaps after the custom client upstream timeout fix) ?

[schzhn]

@bohtho, ensure that the custom client upstream DNS server list is not empty.