# \[FYI\] Google / Chrome: "Experimenting with same-provider DNS-over-HTTPS upgrade"

**URL:** <https://discourse.pi-hole.net/t/fyi-google-chrome-experimenting-with-same-provider-dns-over-https-upgrade/23422>\
**Category:** Off topic\
**Created:** [September 11, 2019, 8:44am UTC](https://discourse.pi-hole.net/t/fyi-google-chrome-experimenting-with-same-provider-dns-over-https-upgrade/23422 "2019-09-11T08:44:08Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![mibere](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/mibere/32/18057_2.png) [@mibere](https://discourse.pi-hole.net/u/mibere)\
**Post date:** [September 11, 2019, 8:44am UTC](https://discourse.pi-hole.net/t/fyi-google-chrome-experimenting-with-same-provider-dns-over-https-upgrade/23422/1 "2019-09-11T08:44:08Z")

</div>

For your information

> As part of our long standing commitment to making the web safer to use, we will be conducting an experiment to validate our implementation of DNS-over-HTTPS (aka DoH) in Chrome 78.  
> [...]  
> Our experiment will run on all supported platforms (with the exception of Linux and iOS) for a fraction of Chrome users. On Android 9 and above, if the user has specified a DNS-over-TLS provider in the private DNS settings, Chrome may use the associated DoH provider, and will fallback to the system private DNS upon error.

[Read full report](https://blog.chromium.org/2019/09/experimenting-with-same-provider-dns.html)

---

<div class="post-metadata">

**Author:** ![dosch](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dosch/32/784_2.png) [@dosch](https://discourse.pi-hole.net/u/dosch)\
**Post date:** [September 11, 2019, 9:44am UTC](https://discourse.pi-hole.net/t/fyi-google-chrome-experimenting-with-same-provider-dns-over-https-upgrade/23422/2 "2019-09-11T09:44:17Z")

</div>

I found that Chrome is now pushing ahead on this as well and that it becomes the default on FF this month.

> **[Experimenting with same-provider DNS-over-HTTPS upgrade](https://blog.chromium.org/2019/09/experimenting-with-same-provider-dns.html)**
>
> Update: Due to a last minute technical issue, we have postponed this experiment to Chrome 79. As part of  our long standing commitment to ...

Is there any more information available on what the impact on pihole users might be?

---

<div class="post-metadata">

**Author:** ![drewski](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/drewski/32/7476_2.png) [@drewski](https://discourse.pi-hole.net/u/drewski)\
**Post date:** [September 11, 2019, 2:46pm UTC](https://discourse.pi-hole.net/t/fyi-google-chrome-experimenting-with-same-provider-dns-over-https-upgrade/23422/4 "2019-09-11T14:46:44Z")

</div>

I'm starting to wonder if they are doing this to get statistics.

---

<div class="post-metadata">

**Author:** ![pidohole](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/p/958977/32.png) [@pidohole](https://discourse.pi-hole.net/u/pidohole)\
**Post date:** [September 11, 2019, 4:37pm UTC](https://discourse.pi-hole.net/t/fyi-google-chrome-experimenting-with-same-provider-dns-over-https-upgrade/23422/5 "2019-09-11T16:37:25Z")

</div>

It depends on how Chrome determines the system's dns. If it simply looks up the OS's dns, then Chrome will not have a corresponding DoH server for your private pihole. But if it does a more exhaustive lookup, such as those on dns leak tests, and the upstream dns of your pihole has a DoH equivalent, then it may the DoH server directly.

---

<div class="post-metadata">

**Author:** ![DL6ER](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dl6er/32/281_2.png) [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)\
**Post date:** [September 11, 2019, 5:16pm UTC](https://discourse.pi-hole.net/t/fyi-google-chrome-experimenting-with-same-provider-dns-over-https-upgrade/23422/6 "2019-09-11T17:16:49Z")

</div>

This is all very speculative.

They could equally well just enforce their own (Google's) DoH server, why even bother trying to find a (reliably working!) local server?...

---

<div class="post-metadata">

**Author:** ![drewski](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/drewski/32/7476_2.png) [@drewski](https://discourse.pi-hole.net/u/drewski)\
**Post date:** [September 11, 2019, 5:22pm UTC](https://discourse.pi-hole.net/t/fyi-google-chrome-experimenting-with-same-provider-dns-over-https-upgrade/23422/7 "2019-09-11T17:22:17Z")

</div>

> [@DL6ER](#):
>
> This is all very speculative.

Very true I shall hush now.

> [@DL6ER](#):
>
> enforce their own (Google’s) DoH server

This would back my theory a little.

---

<div class="post-metadata">

**Author:** ![pidohole](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/p/958977/32.png) [@pidohole](https://discourse.pi-hole.net/u/pidohole)\
**Post date:** [September 11, 2019, 5:27pm UTC](https://discourse.pi-hole.net/t/fyi-google-chrome-experimenting-with-same-provider-dns-over-https-upgrade/23422/8 "2019-09-11T17:27:05Z")

</div>

It's not speculative. If the current dns has a corresponding DoH server then Chrome will automatically switch to DoH. How does Chrome determine if there's DoH server available? It's has a list of supported DoH servers:

- Cleanbrowsing
- Cloudflare
- DNS.SB
- Google
- OpenDNS
- Quad9

This is straight from the horse mouth. [https://www.chromium.org/developers/dns-over-https](https://www.chromium.org/developers/dns-over-https)

---

<div class="post-metadata">

**Author:** ![DL6ER](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dl6er/32/281_2.png) [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)\
**Post date:** [September 11, 2019, 5:30pm UTC](https://discourse.pi-hole.net/t/fyi-google-chrome-experimenting-with-same-provider-dns-over-https-upgrade/23422/9 "2019-09-11T17:30:31Z")

</div>

> [@pidohole](#):
>
> How does Chrome determine if there’s DoH server available? It’s has a list of supported DoH servers

This is in contrast with the quoted blog entry stating:

> By keeping the DNS provider as-is and only upgrading to the provider’s equivalent DoH service, the user experience would remain the same.

My ISP does not offer a DoH equivalent. However, in the future, they might want to enforce the "best" for their users:

> As part of our long standing commitment to [making the web safer to use](https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/) [...]

But, yes, again speculations.

---

<div class="post-metadata">

**Author:** ![pidohole](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/p/958977/32.png) [@pidohole](https://discourse.pi-hole.net/u/pidohole)\
**Post date:** [September 11, 2019, 6:17pm UTC](https://discourse.pi-hole.net/t/fyi-google-chrome-experimenting-with-same-provider-dns-over-https-upgrade/23422/10 "2019-09-11T18:17:15Z")

</div>

Seems pretty clear to me. If you using one of the listed dns, then Chrome will use the DoH. If it's not on the list then Chrome won't make any changes.

---

<div class="post-metadata">

**Author:** ![craigphicks-public](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/craigphicks-public/32/42519_2.png) [@craigphicks-public](https://discourse.pi-hole.net/u/craigphicks-public)\
**Post date:** [July 21, 2024, 4:17pm UTC](https://discourse.pi-hole.net/t/fyi-google-chrome-experimenting-with-same-provider-dns-over-https-upgrade/23422/11 "2024-07-21T16:17:13Z")

</div>

I found that Chromium [Version 126.0.6478.182] is using DoH to tunnel ads DNS to get around PiHole, even if Chromium was set not to use DoH.

See details, and solution, in this post - [Chromium bypasses Pi-Hole by tunneling via DoH - solution is to block google.dns](https://discourse.pi-hole.net/t/chromium-bypasses-pi-hole-by-tunneling-via-doh-solution-is-to-block-google-dns/71330)