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:



Any idea?

8 replies

    • Ruby_Balloon
    • 3 yrs ago
    • Reported - view

    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


    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^


    ^ Rows 99-100

    Is Computer A running Android or a fork of Android?

    • crssi
    • 3 yrs ago
    • Reported - view

    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.



      • olivier
      • 3 yrs ago
      • Reported - view

      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.

      • crssi
      • 3 yrs ago
      • 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.

    • crssi
    • 3 yrs ago
    • Reported - view

    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.

      • olivier
      • 3 yrs ago
      • Reported - view

      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.

    • olivier
    • 3 yrs ago
    • Reported - view

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

    • crssi
    • 3 yrs ago
    • Reported - view

    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.


Content aside

  • 3 yrs agoLast active
  • 8Replies
  • 967Views
  • 4 Following