FQDN DNS server fastest IP priority

[pduchnovsky]

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 request a feature or enhancement and not ask a question

The problem

When using dns0 or quad9 providers it very often happens that AdGuard home instance starts using slower IP from the dns provider (For DNS queries). e.g. when using h3://zero.dns0.eu upstream, they work over two IPs essentially - 193.110.81.9 and 185.253.5.9 The first IP has the lowest latency and fastest response time while the second IP has slower response and much higher latency for me. However AdGuard begins to route requests through the second IP most of the time.

When using h3://193.110.81.9 instead, everything is fast.

Proposed solution

AdGuard should be at least testing latency via ping and prioritizing the faster server IP

Alternatives considered and additional information

No response

[fernvenue]

Have you ever tried fastest_addr mode as your upstream_mode just like documentation said?

[pduchnovsky]

@fernvenue based on my understanding that slows down (adguard) response time in general since then AdGuard queries and waits for all upstream responses and tests for fastest IP for the Query (not fastest dns server) so how would that help ?

I think adguard home instance should use the fastest_addr when querying for resolving of upstream FQDN though.

[fernvenue]

Well, if you wanna use the fastest IP, you need that, and if you wanna use the first response, than you need all_servers to enable parallel queries to all configured upstream servers to speed up resolving. As documentation said:

all_servers (before v0.107.44): Enables parallel queries to all configured upstream servers to speed up resolving. If enabled, the queries are sent to each server simultaneously and the first response is chosen. If disabled, the queries are sent to each upstream server one-by-one and then sorted by RTT. Note that more stable upstream servers are preferred by the algorithm.

Whether you want the fastest result returned or the fastest one among all the results returned, I think these two options can fully meet your different needs.

[pduchnovsky]

@fernvenue You probably don't understand what I wrote in my initial post. My problem is NOT adguard home returning answers from client queries. My problem is that adguard home when querying bootstrap servers for upstream fqdn, it does not then use fastest IP returned from bootstrap servers for the upstream queries.

[fernvenue]

My problem is that adguard home when querying bootstrap servers for upstream fqdn, it does not then use fastest IP returned from bootstrap servers for the upstream queries.

Even when you enabled fastest_addr mode? I thought bootstrap servers will also respect that option, at least in my tests.

[pduchnovsky]

My problem is that adguard home when querying bootstrap servers for upstream fqdn, it does not then use fastest IP returned from bootstrap servers for the upstream queries.

Even when you enabled fastest_addr mode? I thought bootstrap servers will also respect that option, at least in my tests.

I dont want to enable fastest_addr because it then slows down ALL client queries because adguard has to wait for all upstreams, then does test the speed towards response IP... my suggestion is pretty clear, adguard should use fastest_addr equivalent itself for bootstrap server queries automatically, so it then uses fastest upstream IP. This should be decoupled from the fastest_addr setting. I want to use parallel requests of course, for speedy responses to the clients.

[fernvenue]

Ah, things are much clearer now. I agree with you on this point, these two options should be allowed to separate :)

[Sakura-Luna]

• parallel: Parallel queries to all configured upstream servers to speed up resolving.

Why don't you discuss Parallel? It should return results the fastest.

[pduchnovsky]

@Sakura-Luna

I use parallel requests, the problem is, adguard queries BOOTSTRAP server to resolve zero.dns0.eu, (assuming) gets two IP's (193.110.81.9 and 185.253.5.9) and then decides to use second slower IP instead of using the fastest one.

Otherwise I can't explain why queries are so much slower when using h3://zero.dns0.eu, but they are blazing fast when using h3://193.110.81.9 instead.

EDIT: I just queried the zero.dns0.eu and it seems to only provide a single IP, as laddr::

root@d-server:~# q zero.dns0.eu
zero.dns0.eu. 10s A 195.146.2.117
zero.dns0.eu. 10s A 5.181.77.52
zero.dns0.eu. 0s TXT "ecs: none"
zero.dns0.eu. 0s TXT "laddr: 193.110.81.0:443"
zero.dns0.eu. 0s TXT "proto: DOH3"
zero.dns0.eu. 0s TXT "raddr: xxxxxxxxxxxxx"

So probably in this case I think the problem is not on the end of adguard home instance, but rather the DNS provider itself ? Right now it is responding with the faster IP, but I am assuming it also switches to the slower IP and this is where the problem happens, when adguard resolves the slower IP and starts using it.

*Compared to quad9, which provides both IPs:

root@d-server:~# q dns11.quad9.net
dns11.quad9.net. 20m A 149.112.112.11
dns11.quad9.net. 20m A 9.9.9.11

Therefore I am closing this issue, there is probably nothing adguard team can do with this.

EDIT2: My assumption was correct.. they keep changing the IPs often, and use 0s ttl, terrible practice if you ask me:

root@d-server:~# q zero.dns0.eu @9.9.9.11 | grep laddr
zero.dns0.eu. 0s TXT "laddr: 193.110.81.101:53"
root@d-server:~# q zero.dns0.eu @9.9.9.11 | grep laddr
zero.dns0.eu. 0s TXT "laddr: 185.253.5.101:53"

EDIT3: Problem resolved by using boostrap server 9.9.9.11 instead of default one, as per suggestion from quad9 support. Now getting proper routing for dns0.eu requests probably thanks to use of edns.