For Developers‎ > ‎

DNS over HTTPS (aka DoH)

Motivation

When you navigate to a website, your browser first needs to determine which server is responsible for delivering said website, a step known as DNS resolution. With DNS over HTTPS, all DNS resolutions occur over an encrypted channel, helping to further safeguard user security and privacy.


Auto-upgrade project

Links: PSA, design doc, crbug

For a first milestone, we are considering an auto-upgrade approach. At a high level, here is how this would work:

  • Chrome will have a small (i.e. non-exhaustive) table to map non-DoH DNS servers to their equivalent DoH DNS servers.

  • Per this table, if the system’s recursive resolver is known to support DoH, Chrome will upgrade to the DoH version of that resolver. 

  • On some platforms, this may mean that where Chrome previously used the OS DNS resolution APIs, it now uses its own DNS implementation in order to implement DoH.

  • A group policy will be available so that Administrators can disable the feature as needed

  • End-users will have the ability to opt-out of the experiment from Chrome 78 by disabling the flag at chrome://flags/#dns-over-https.


In other words, this would upgrade the protocol used for DNS resolution while keeping the user’s DNS provider unchanged.

It’s also important to note that DNS over HTTPS does not preclude its operator from offering features such as family-safe filtering.


We've enabled an experiment in Chrome 79 for a fraction of our users.


Providers in the mapping table

For the experiment, we’ve intentionally kept the list small but reasonably diverse.

Here are the providers that we have selected in alphabetical order:

  • Cleanbrowsing

  • Cloudflare

  • Comcast

  • DNS.SB

  • Google

  • OpenDNS

  • Quad9


The list will be reviewed and potentially extended for any follow-up launch.

Send suggestions to doh-provider@chromium.org

For technical questions, please send an email to net-dev@ with the [DoH] prefix in the subject line.


FAQ

Q: Do you plan to support a canary domain similar to Mozilla's use-application-dns.net?
A: We have no plans to support this approach. We believe that our deployment model is significantly different from Mozilla's, and as a result canary domains won't be needed. In particular, our deployment model is designed to preserve the current user experience, i.e. auto-upgrading to the current DNS provider's DoH server which offers the same features.

Q: How will Chrome's auto-upgrade approach work with Split Horizon?
A: Chrome's auto-upgrade approach does not change the DNS provider, and is designed to preserve the same user experience. Split Horizon setups should continue to work as is. Furthermore, managed deployments should be automatically opted-out, and administrators can use policies to control the feature.
Comments