AdguardTeam
Dashboard: destinations database looks like it has a bug? 'unknown destination' is top country.
Platform
Other
Protocol
DNS-over-HTTPS
Do you use AdGuard app?
No I don't
Your configuration
I'm using adguard-dns.io
Traceroute to AdGuard DNS
not needed
Issue Details
- Login into adguard-dns.io dashboard
- look at Top destinations
- most used 'country' is 'unknown destination'
Expected Behavior
unknown destinations shouldn't be the main country. Looks like country-databse linking doesn't work as it should or something is broken?
Actual Behavior
See screenshot and issue details above.
Screenshots
Screenshot 1:
Additional Information
No response
Hello there!
The situation you describe is not a bug. Indeed, most of the requests in this case were made from IP addresses of an undefined country.
In the future, we will split the Unknown destenation category into two. Certain addresses from undefined countries will fall into the first category. The second category responses to queries do not contain IP addresses, so it is not possible to determine the country
Thanks for your feedback. But actually I don‘t understand what you mean in detail?
When looking at the query logs and seeing the unknown IPs and trying to put them into some other search engines I do get results… But could it be the case, that they‘re wrong, because they are CDNs and so on?
Would be nice to get some more details on your feedback.
Thanks for your nice product.
In the future, we will split the Unknown destenation category into two.
Any update, when this feature will come up?
We are already working on it, I can't give you an exact date but we expect this change in the nearest future. As soon as it is added I will let you know.
Released 🎉
Can we somehow see, when the release is showing up in public? Will this be v2.8.0? Within my Web-GUI everything looks like before.
Ok - but then there is still something still broken somehow?
Checked my query logs of the last hour and still seeing a lot of unknown destination. And there are a lot of destinations which should be really well known (Telekom, adguard-dns.com domain, adguard-dns.io, and many else - they are all showing unknown destination).
We will set up the above functionality shortly, I will let you know, thank you
We will set up the above functionality shortly, I will let you know, thank you
Looks like it is 'live'. Thanks for your work. Will test it.
Another point to mention here: Would be nice to see some kind of versioning (and changelog) within AdGuard DNS dashboard, so you know which version you're on and what maybe changed. So you have it in one place and do not need to read blog entries and/or newsletters.
In the future, we will split the Unknown destenation category into two. Certain addresses from undefined countries will fall into the first category. The second category responses to queries do not contain IP addresses, so it is not possible to determine the country
Now 'not applicable' is on place 1 of my top destinations. 😃
If I look inside and check the queries with other geo databases they can clearly say from which country it is (and many of them have one/more IP addresses the resolve to).
Enclosed a few examples of clear domains where are definitively countries behind...
At least with your own AdGuard domain there should be a correct result?
We don`t use the HTTPS for DNS protocol. We use DNS-over-HTTPS (DoH) So if you make a request you can make sure that there will be no response for such a request.
dig @$Yourserver 'status.adguard.com' HTTPS IN
Hi,
looks like the destinations are still kind of buggy.
'Not applicable' is on place 1 of my top destinations - by far. Why so? Other providers can tell which countries those requests are going to. Is there something broken within your geo-databases?
And there are also some kind of wrong destination countries showing up.
For example: All those requests to *.fastmail.com displays "Australia" as the country - which is not the case! Fastmail doesn't have servers within Australia - it is an Australian company with servers in US.
Looks like something is broken/buggy here.
Hello there!
- Response doesn't include IP address. As I wrote above We don`t use the HTTPS for DNS protocol. We use DNS-over-HTTPS (DoH). So if you make a request you can make sure that there will be no response for such a request. Therefore, there can be quite a few such requests
- According to MaxMind GeoIP2 ISP database, Fastmail prefixes are attributed to Perth, Western Australia. You can check it by yourself via their service.
@Chinaski1 Thanks for your feedback. Concering 2. - I got it. MaxMind is (like often) the issue in that case. db-ip.com is much more accurate than MaxMind!
I think we need to reopen this part, as most of the queries are still shown as unknown or undefined.
When comparing to other providers (see ControlD for example) it does nearly always show the right answering country. Why is it not possible for AdGuardDNS to do the same?
Any update over here? Not applicable is still on top of the list and unknown destination is also high up.
I don't know if it's the list from MaxMind you're using (see https://github.com/AdguardTeam/AdGuardDNS/issues/779#issuecomment-2452964787) or if it's something else.
Comparing to ControlD for example they show nearly all destinations as it should be. Maybe they're using something else instead of MaxMind or maybe there is a bug within your list.
Even "status.adguard.com" within the logs is showing "not applicable". So definitely something broken! @Chinaski1