DNS over HTTPS Is Coming to Firefox and Chrome

Before a browser does any TLS handshake, it asks a DNS resolver where a hostname lives, and that question and its answer usually travel as plain UDP that anyone on the path can read or tamper with. Within a few days of each other this month, Mozilla and Google both announced plans to change that in their browsers by default, at least for some users. They’re doing it in very different ways, and if you run a network, a filter, or an internal DNS zone, the differences matter.

I’m sticking to the RFC and to what Mozilla and Google have published themselves.

What DoH actually is

RFC 8484, published in October 2018 by Paul Hoffman of ICANN and Patrick McManus of Mozilla, defines DNS Queries over HTTPS. The idea is simple: each DNS query and response pair becomes an HTTP exchange. The client is configured with a URI template for a DoH server, and it sends the ordinary DNS wire format message either as the body of a POST or base64url encoded in a dns parameter on a GET. The media type is application/dns-message, and servers have to support both methods.

Because it all rides on https URIs, you get TLS integrity and confidentiality. The privacy section says this mitigates passive surveillance and active attempts to divert DNS traffic to rogue servers. It also points out that using port 443, and mixing DoH with other HTTPS traffic on the same connection, makes the lookups harder to single out and interfere with.

The RFC is just as frank about the cost. Its operational considerations section says filtering or inspection systems that rely on unsecured DNS won’t work in a DoH environment. That one sentence is basically the whole controversy.

What Mozilla announced

Mozilla posted What’s next in making Encrypted DNS-over-HTTPS the Default on September 6. It says Mozilla has been running DoH experiments in Firefox since June 2018, that more than 70,000 users have already turned it on themselves in the release build, and that it plans to gradually roll out DoH in the USA starting in late September. The rollout starts with a small percentage of users, and Mozilla says it will announce when it’s ready to go to 100%. Users will be notified when DoH is enabled and given the chance to opt out.

The post itself doesn’t name a resolver. The DoH performance studies Mozilla has written about have used Cloudflare’s DoH service, and Mozilla’s original Nightly post explains that Cloudflare was picked because it agreed to a strong privacy agreement.

Mozilla is deploying in what it calls fallback mode. If a DoH lookup fails, or one of its heuristics fires, Firefox goes back to the operating system’s DNS. The post lays out three rules: disable DoH when opt in parental controls are detected, disable it when enterprise policies are present unless a policy explicitly turns it on, and fall back to the OS when split horizon setups or other DNS problems cause lookups to fail. Mozilla’s latest US study gives a sense of scale: 4.3% of users in it used OpenDNS parental controls or Google safe search, and 9.2% triggered one of the split horizon heuristics, which fired on domains with non public suffixes and on lookups that returned both public and private RFC 1918 addresses.

For network operators, the interesting piece is the canary domain. Mozilla’s support page on configuring networks to disable DoH says networks can signal that their resolver does things DoH would break. On top of that signal, Firefox will run its own checks at startup and whenever it moves to a different network: it resolves the safe search variants of google.com and youtube.com, looks for OS parental controls on Windows and macOS, and checks whether security.enterprise_roots.enabled is true or any enterprise policy is configured. If a user turned DoH on by hand, the network signal is ignored.

The signal itself is use-application-dns.net. According to Mozilla’s canary domain page, Firefox resolves it through the OS resolver and treats NXDOMAIN, SERVFAIL, or an answer with no A or AAAA records as a reason to disable DoH. Mozilla describes it as an interim measure until a standards body defines a real way to signal DNS filtering. The blog post adds that it’s meant for networks where users opted in to parental controls, and that Mozilla will revisit it if it gets abused.

What Google announced

Google took a narrower approach. The Chromium blog post Experimenting with same-provider DNS-over-HTTPS upgrade, from September 10, describes an experiment in Chrome 78. Chrome checks whether the user’s current DNS provider is on a list of DoH compatible providers and, if it is, switches to that same provider’s DoH service. If the provider isn’t on the list, nothing changes. If DoH fails, Chrome reverts to the provider’s regular DNS.

The experiment covers a fraction of users on every supported platform except Linux and iOS. On Android 9 and later, if someone has set a DNS over TLS provider in private DNS settings, Chrome may use the matching DoH provider. Users can opt out by disabling chrome://flags/#dns-over-https. At announcement time, Chromium’s DoH project page listed Cleanbrowsing, Cloudflare, DNS.SB, Google, OpenDNS, and Quad9 as the providers in the mapping table.

Because the resolver doesn’t change, Google argues that existing filtering from that provider keeps working. The Chromium DoH page says Google has no plans to support Mozilla’s canary domain, that split horizon setups should continue to work as is, and that managed deployments should be automatically opted out. The blog post says most managed Chrome deployments are excluded and that details on DoH policies will come in upcoming enterprise release notes.

Who gains and who has to adjust

The privacy win is real but specific. DoH protects your lookups from the network between you and the resolver: the coffee shop Wi-Fi, a compromised router, an ISP that watches or rewrites plain DNS. It doesn’t hide your queries from the resolver itself, which is why Mozilla leans so hard on the contract with its resolver. And as the Nightly post notes, connecting to a site still means sharing its name with third parties no matter how you resolved it.

The people who have to adjust are anyone who uses the local resolver as a control point. That includes schools and parents with DNS based filters, security teams that block malware domains at the resolver, and companies with split horizon zones where jira.corp.example only resolves inside the office. Google says its same provider design keeps those features working, since the resolver stays the same. Firefox’s design moves lookups to a different operator, so it relies on the canary domain, the heuristics, and the fallback to keep those networks working.

What I’d do as an admin or developer

First, find out what your browser is actually doing. In Firefox, network.trr.mode in about:config shows the DoH setting, and the Nightly post says the DNS tab on about:networking shows which names were resolved over DoH. In Chrome 78, the experiment is controlled by the chrome://flags/#dns-over-https flag.

If you run a filtering or split horizon resolver and want Firefox to stay on it, make your resolver return NXDOMAIN for use-application-dns.net, then check from a client on that network that it really does.

dig use-application-dns.net A

Managed Firefox installs have a cleaner option. Mozilla’s policy templates include a DNSOverHTTPS policy, documented for Firefox 63 and ESR 68, with Enabled, ProviderURL, and Locked keys. It can be set through Group Policy, a macOS configuration profile, or a policies.json file in the distribution folder. To turn DoH off and stop users flipping it back on:

{
  "policies": {
    "DNSOverHTTPS": {
      "Enabled": false,
      "Locked": true
    }
  }
}

Mozilla says any enterprise policy already disables the default rollout, but I’d set this one explicitly so the intent is written down. If you run your own DoH server, Enabled plus ProviderURL lets you keep both the encryption and your resolver. For Chrome, Google says managed deployments are mostly excluded, and the policy details aren’t out yet, so watch the Chrome enterprise release notes.

Finally, don’t treat DNS filtering as a wall. A canary domain is something a browser chooses to honor, and a user can turn DoH on manually and skip it entirely. Any app can ship its own resolver. If blocking a domain actually matters for security or compliance, back it up with egress controls, a proxy, or endpoint software rather than trusting that every client asks your resolver.

The resolver is now a choice

What really changed this month is that the browser, not the operating system or the network, now gets a say in who answers DNS. Google is using that to upgrade the transport while keeping your provider. Mozilla is using it to pick a provider with a privacy contract, and backing off on networks that ask. Both are defensible. If your security model assumed every lookup passes through your resolver in plain text, now is a good time to fix that assumption.