Try to improve the fallback approach

[ameshkov]

Issue Details

First of all, why do we need a fallback? We faced issues with nameservers for unknown reasons preventing access from our name servers. There were not too many, but still this is a pretty problematic issue for AdGuard DNS users.

Currently, we do the following: if the recursor returns a SERVFAIL response, AG DNS tries to use a fallback.

Unfortunately, this leads to issues like that: https://github.com/AdguardTeam/AdGuardDNS/issues/653

Proposed solution

1. The simple solution would be to use the fallback only once per eTLD+1 domain. If the fallback also returns a SERVFAIL response for that domain name, remember this and don't use the fallback anymore.
2. Disable fallbacks for specific domain zones.

Alternative solution

If we had a pure go recursor implementation we could come up with a more sophisticated solution, but we don't.

[ghost]

@ameshkov, I'm currently experiencing this with AdGuard DNS in Sydney, Australia, should I be reporting this to AdGuard as something that can be resolved? If so, how long does getting does this type of issue usually take to resolve?

[ameshkov]

It's planned to be resolved in the version v2.6.

You mean that a DNS check shows a wrong resolver? It needs to be resolved because it's generally suboptimal, but it does not affect the service operation so categorized as a minor issue.

[ghost]

Thanks, I hadn't noticed any performance degradation, so wasn't too concerned.

The reference to 'resolved' was not regarding dns resolving, but issue resolving.

I'm experiencing the same issue as the one linked to this issue where I'm seeing a lot of Google ns connections when using AGDNS, and couldn't work out why until I saw this GH issue. I don't understand why it's happening, but at least it's known about.

[ameshkov]

where I'm seeing a lot of Google ns connections

Where exactly do you see them?

[ghost]

The same place as on the original issue, dnscheck.tools. It's the only method I've found that propagates a list of all dns resolvers being used.

All other methods will only show me seemingly the most dominant one. In my case, iCloud Private Relay.

[ameshkov]

Got it. No worries then, it's a nuisance that we'll fix in the future, but not a major one.

[emeritaacuity0u]

It's planned to be resolved in the version v2.6.

You mean that a DNS check shows a wrong resolver? It needs to be resolved because it's generally suboptimal, but it does not affect the service operation so categorized as a minor issue.

@ameshkov Did this end up getting resolving in v2.6? I'm seeing a fallback to Google on IPv4 and IPv6, so I assume it didn't?