domain-specific upstream not tested

[MkQtS]

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.107.6
• How did you install AdGuard Home:
  • GitHub releases
• How did you setup DNS configuration:
  • Router
• CPU architecture:
  • AMD64
• Operating system and version:
  • OpenWrt 21.02

Expected Behavior

Set upstream DNS servers like this:

[/example.com/]server1
server2
server3

When server1 doesn't work and other servers works well, click Test upstreams, ADGH should report server1 has a problem.

Actual Behavior

ADGH reports all servers work correctly. The server which only applied to specific domains is not tested.

[fernvenue]

Actually AdGuardHome will send a type A request of google-public-dns-a.google.com to the target upstream server to test if upstream servers working or not. So here's the problem, how to test specific upstream? What if the upstream only work for that specific domains?

Here's an example, we have an upstream server 10.0.0.1 only work for a.lan, b.lan, c.lan and so on, now we use the rule like [/lan/]10.0.0.1, and how AdGuardHome should do?

And the another problem is, sometimes we use upstream_dns_file to define a lot of rules in one list, if we already find a way to test specific servers and solved the problem above, how to make sure AdGuardHome can test all upstream servers in the list as quickly as possible, and make sure we are not gonna abuse any server?

So...I think it will be so hard to do that :(

[MkQtS]

Your explainations are convincing and it sounds hard.

It makes me confusing when a certain domain-specific upstream didn't work and I tried to use ADGH to test but ADGH didn't report anything. I think some explanation in the web UI would be helpful.

For the testing strategy, how about testing those public DNS servers as normal and testing private servers using a configured domain? Some rules may be too complex or too general to test, like a big list or [/lan/]10.0.0.1, those rules can be directly ignored and then give a notification to the user.

[fernvenue]

@MkQtS I agree with you, telling user in the web UI that some upstream will not be tested might be a good way for now.

[EugeneOne1]

@MkQtS, @fernvenue, we've finally improved the tests. Each upstream (including domain-specific ones) now tested with test. TLD as per RFC 6761. Also, if domain-specific upstream fails the test, an appropriate warning will be displayed. Those errors aren't critical and still may be followed by a green message about success so only tests of non-specific upstreams are blocking.

Could you please check, if our implementation works properly?

[MkQtS]

@EugeneOne1, I've tried the edge build, it works totally fine. However, Server "[/domain/]server" looks weird, would it be better to use Server in "[/domain/]server"?

[EugeneOne1]

@MkQtS, great, thanks for testing it.

If I got it correctly, you're trying to point out the difference between an upstream server's configuration line and an upstream server itself?

[MkQtS]

If I got it correctly, you're trying to point out the difference between an upstream server's configuration line and an upstream server itself?

@EugeneOne1, yes. I mean the phrase Server "[/domain/]server" in the error message, I don't think the specified domain name should be considered as a part of a server.

[EugeneOne1]

@MkQtS, the wording should now be fixed in the latest edge. I think I can close the issue for now, the suggestions and notions are still welcome.