For Developers‎ > ‎

DNS over HTTPS (aka DoH)


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.

Same-Provider Auto-Upgrade

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 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. In other words, this would upgrade the protocol used for DNS resolution while keeping the user’s DNS provider unchangedIt’s also important to note that DNS over HTTPS does not preclude its operator from offering features such as family-safe filtering.

  • 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 control the feature from the settings page (e.g. disable, auto-upgrade, choose or specify a specific provider)

We've enabled an experiment in Chrome 83 for a fraction of our users with the following scope.

  • Platforms: Windows, Mac, Chrome OS. (Support for Android and Linux is planned for after M83)
  • Default experience: same-provider auto-upgrade (i.e. the behavior outlined above and tested in Chrome 79).
  • Setting in the “Privacy and Security” section to allow users to control and configure the feature in the rare cases where the default behavior wouldn’t meet their needs. This will include the ability to completely disable DoH, as well as manual configuration options. The setting will default to an automatic mode which corresponds to the “same provider, auto-upgrade” behavior we’ve been testing in the Chrome 79 experiment.
  • For users who fall into any of the following conditions, the setting will be locked down and DoH related command line options (if any) will be ignored:
    • If OS parental controls are detected -> locked in "off" (subject to the availability of APIs provided by the OS).
    • DoH set via enterprise policies -> locked with a state reflecting the enterprise policies
    • Detected managed environment (but no DoH enterprise policies set) -> locked in "off"

DoH Providers

Here are the providers from milestone 83 and beyond:

ProviderAuto-upgradeableSettings Countries
 Cloudflare ✓*
 Comcast ✓ (N/A)(N/A)
 Google ✓*
 OpenDNS(M85: TBC)(M85: TBC) 
 Quad9 *
 CZ.NIC ODVR(M84: ✓) (M85: TBC) CZ
*: worldwide

As we move forward with the rollout, we may have to temporarily remove specific providers if they need more time (e.g. scale the backend, etc). There might also be some last minute additions/removals depending on final checks. See the requirements and process.

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


Q: Do you plan to support a canary domain similar to Mozilla's
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.