2

metric.gstatic.com is not blocked but it should be

metric.gstatic.com is on a DenyList AdGuard DNS filter

As you can see on the picture first (the bottom one) request was from computer A and was not blocked.

The second one (the top one) I have requested for a test from computer R and it was blocked as it should be.

 

The AdGuard DNS filter list was not refreshed in between the two requests, the last update was 5hrs before that event.

 

The problem is still on-going... all the requests from computer A goes out as not-denied.

Here are some samples:

dd6e33ef-dnsotls-ds.metric.gstatic.com
qa5s95-dnsotls-ds.metric.gstatic.com
wzb86v-dnsotls-ds.metric.gstatic.com
280c9249-dnsotls-ds.metric.gstatic.com
957vl1-dnsotls-ds.metric.gstatic.com
mikpvw-dnsotls-ds.metric.gstatic.com
900912f0-dnsotls-ds.metric.gstatic.com
xul6n2-dnsotls-ds.metric.gstatic.com

 

Any idea?

8replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • A reddit search references Google uses this domain to test ipv4 and ipv6 connectivity (using adwords). In your case, it would be  testing these connectivities over TLS

    https://www.reddit.com/r/netsec/comments/10j6oz/strange_metricgstaticcom_domains_cookies_in_dns/

    Also there's a couple of adguard exceptions:

    Overview: Fixing the issue with "Wi-Fi" connection mark when you configure private DNS on Android9
    ! Once you enable private DNS, Android 9 starts resolving random domains looking like
    ! `*-dnsotls-ds.metric.gstatic.com` (for instance, `a5a6380f-dnsotls-ds.metric.gstatic.com`).

    Details: ! AdGuard DNS blocks this domain but for some reason, it messes with Android's network validation process. @@dnsotls-ds.metric.gstatic.com^

    https://github.com/AdguardTeam/AdGuardSDNSFilter/blob/master/Filters/exceptions.txt

    ^ Rows 99-100

    Is Computer A running Android or a fork of Android?

    Like 1
  • Hi Greg

     

    Thank you for trying to help, but you got it all wrong. Also I know already all that.

    It is not a question who and why is using those queries.

    It is not a question which OS is the device that is querying those.

     

    The only question is, why the DNS query from device A is not denyed, when when I do the same DNS query from device R and it is blocked.

     

    Cheers

    Like
    • crssi greg is actually all right. We have a hard coded exception for this domain when accessed thru DoT in order not to break Android private DNS.

      Like 1
      • crssi
      • crssi
      • 1 yr ago
      • 1
      • Reported - view

      Olivier Poitrey Actually Greg would be right if he would say the same as you... where the reason is being allowed hardcoded by nextdns, which is not that Gerg was saying. ;)

      Now, the question is, where can I see what is hardcoded, since this is not cool, that something is allowed even when expected is different... I guess that kind of requests should be marked in the log (orange color for example, beside red and green used now).

      It simply is not cool that I see the list having that entry and the NextDNS behavior is somehow different. In some eyes this would shine like NextDNS is silently in being favor of google... I believe that is not so, but someone could get it so. Please, make that transparent for us.

      Why... because here I can't find that metric.gstatic.com is being hardcoded as allow: https://github.com/nextdns/metadata/blob/master/privacy/blocklists/adguard-dns-filter.json

      Where can I find the list of such hardcoded allowlist?

      Additionally, I have manually denied now the metric.gstatic.com and cannot see any problems on androids ATM... but it is still too soon to conclude, its running so for the last 12hrs only now.

      Like 1
  • On one of the profiles I have NextDNS option of DenyList named "No Google".

    There are no Private DNS android devices ATM on, but it it were... what would happen with DoT metric.gstatic.com requests.

    I must admit I am very disappointed ATM and my trust has been for the first time greatly compromised. 😢

    This kind of options MUST be transparent and MUST be an opt-in option.

    I hope for a fast and accurate response which will hopefully prove my wrong.

    But, at the same time, I am glad that you have admit the real reason, so I don't throw away my time for investigation.

    Like 1
    • crssi if you block this domain with private dns on android, it breaks your network with no clue on what is going on. As there is no way to know when it is an android querying us, we applied this exception when the DoT protocol is used. This protocol is mostly used by android users, adoption is pretty low, so it a reasonable “targetting”. From our knowledge, blocking this domain pattern is always going to break something.

      This is one of the rare trick we put very early on in, to make our solution work with the different OSes. We could add a nob “Avoid breaking Android Private DNS” but I fear it would confuse people and make our product more complex for little value.

      Like 1
  • To be specific, we only unblock *-dnsotls-ds.metric.gstatic.com, not all *.metric.gstatic.com.

    Like
  • Understood. That would be OK if user would know somehow about the reason and if there those exceptions would be published somewhere to make it transparent and user would still have control.

    1. Could you, please, mark this kind of requests in the log so user will know what is happening.

    2. Please, publish somewhere such "eastern eggs" to avoid some privacy related wanna be theory of conspiracy fiasco.

    3. It would be much better that user can decide about that, like option "Allow Affiliate & Tracking Links" in the settings.

    ATM this is the same categpory as Apple did with allowing calling home even when firewall was set different... the fiasco that they corrected now. And that is not cool. That is not cool.

    If you think it is a problem for user, then make it opt-out in the settings.

    Cheers

    Like 1
Like2 Follow
  • 2 Likes
  • 1 yr agoLast active
  • 8Replies
  • 398Views
  • 4 Following