Skip to content
Naked Security Naked Security

Mozilla faces resistance over DNS privacy test

Is Mozilla’s enthusiasm for DNS-over-HTTPS getting out of hand?

Is Mozilla’s enthusiasm for Cloudflare’s DNS-over-HTTPS (DoH) service getting out of hand?
Cloudflare launched its 1.1.1.1 public DNS resolver on 1 April, one of the first anywhere to support DoH, an emerging technology designed to secure Domain Name System (DNS) queries from prying eyes such as governments, ISPs, and the like.
Because browsers as well as DNS resolvers must support the DoH protocol, Mozilla adopted Cloudflare as its test partner with a view to integrating the technology in Firefox 62, due in September.
But supporting DoH in a browser isn’t as simple as just enabling the protocol. Mozilla must also decide whether this support is enabled by default and, if so, which DoH server, or “Trusted Recursive Resolver” (TRR) it points to when the browser launches.
It turns out that Firefox’s DoH Shield test beta has already embedded Cloudflare as the default TRR, which hasn’t gone down well with everyone on several counts:

  • It puts a lot of trust in a company that’s already plugged into a lot of websites.
  • Using one service is an obvious single point of failure (SPOF).
  • DoH resolvers should be opt-in, not opt-out.
  • It silently overrides your existing DNS settings.

From the Ungleich blog:

When Mozilla turns this on by default, the DNS changes you configured in your network won’t have any effect anymore. At least for browsing with Firefox…

The obvious reply is that Mozilla’s developers have set Cloudflare as the default TRR as part of the testing process and are unlikely to impose this setting on users when the capability is offered to the world in Firefox 62.
As Firefox blogger Martin Brinkmann points out, the default TRR can be changed quite easily from about:config:

It is already possible to run custom DNS over HTTPS servers and Firefox’s current implementation allows custom addresses to be used.

But even if Mozilla makes the TRR opt-in, it’s possible to spy the beginnings of a dilemma about how best to implement a technology that ideally should be on all the time without non-expert users having to think too hard about what it is or how it works.


As Mozilla’s Lin Clark wrote in her excellent DoH explainer in May:

We’d like to turn this on as the default for all of our users. We believe that every one of our users deserves this privacy and security, no matter if they understand DNS leaks or not.

Most likely, a decision about which DoH resolver to use in Firefox is some way off but it’s a bridge that won’t be easy to cross in a community as sensitive to privacy as Mozilla’s.
The alternative is to go back to the traditional model of letting people choose for themselves, as they do today for conventional DNS resolvers and search engines.
A reminder of why this less exciting approach might not be a bad idea after all came when Cloudflare’s DNS suddenly stopped resolving on 31 May for 17 minutes because of a configuration cock up. The counter-argument is that this weakness applies to any DNS or DoH provider and could be countered with a backup resolver.
The dream of a private internet might look as if it’s going well with Google’s tough stance on shaming sites that don’t use HTTPS having an effect. But there is still much hard work to do, as the IETF’s work on the related issue of Encrypted Server Name Identification (ESNI) privacy underscores.
That being said, there are always too many privacy holes that need filling at any one time. Doing something about one of the larger ones, DNS privacy, would feel like much-needed progress.

10 Comments

If Mozilla allows users choice, then Mozilla will keep their following. I think they understand that.

I feel it’s a necessary step to just pick a particular egg in this chicken-and-egg problem, where there aren’t yet enough DoH servers yet to provide a satisfying array of host options.
I expect that after this is released to popular numbers, many more DoH servers will pop up, and the Mozilla team will create a satisfying server-group infrastructure. They have been serving the public trust pretty well so far, and it will be to their benefit to continue enforcing that trust.

Have used Quad9 since its inception and have never had an issue. Using OpenDNS as a backup.
Also there is a trust issue… Cloudfare has made more than one “bungle” and has slowed connections to legit sites.
Also with FF’s policy of reducing its features (Live Bookmarks for one) I am actively searching for alternatives (Vivaldi and PaleMoon are the top two so far).

“It silently overrides your existing DNS settings” – how does this play out when using DNS lookup through a VPN provider? When I use a VPN I expect my traffic to be routed through the VPN provider, not derailed and sent elsewhere. The VPN providers I use take control of DNS.

Your traffic will still go through the VPN (assuming you aren’t using a so-called ‘split tunnel’, which is jargon for a setup where some traffic is, and some traffic isn’t, routed through the VPN’s network driver).
But if that traffic is ultimately aimed at, say, the CloudFlare or Google DNS-over-HTTPS server, that’s where it will go once it exits the VPN into the real world.
A VPN provider can’t “take control” of DNS-over-HTTPS – at least, not easily – for the same reasons that a VPN can’t silently snoop on the content of HTTPS traffic in general.
In the Firefox about:config, you can either turn off TRR entirely, or set your own DNS-over-HTTPS (DoH) provider. Currently you’re pretty stuck with CloudFlare or Google for free public DoH service (anyone know of others that are currently active?). But if you already trust your VPN provider to reply to all your DNS requests, then why not ask them if they plan to offer their customers DoH? Seems as though it might be a cool feature for a forward-looking VPN…

“[DoH] might be a cool feature for a forward-looking VPN”.
If I use a VPN, is not all my traffic encrypted as far as the VPN service provider’s machine room? So, if I am doing my domain name look-ups on a server in that provider’s machine room, how would my browser using encryption when interrogating that name server really help me?
Yes, there is some security in depth, in that anyone who can spy on the VPN traffic (i.e. is inside the virtual network and sees the packets without the encryption used to run it over the public Internet) would not be able to record the domain names I am looking up, unless he also has the private key for the DoH server. However. broadly, this just means I am trusting the VPN company and its employees twice instead of once.
If I use an independent DoH server, out the other side of the VPN, making friends with the VPN company would not help Mrs May.

I think you answered your own question there :-)
I prefer to think of it the other way around – end-to-end encryption from the client software right to to the server running the service you’re using…
…and then wrap a VPN round that. (Are you sure your VPN service provider’s DNS servers really are “in the machine room” where your VPN tunnel terminates? And not across the hallway, or across the road, or interstate, or even across the border, where electricity is cheaper and the climate cooler? Should you have to be sure? Seems that the longer and more end-to-endly your data is encrypted, the better.)

Even you use VPN while you use Firefox, you still go over DoH
just go in about:config, search for “trr” and change to 0 to disable it.
otherwise, just config to 2 and use third-party DoH server

Strictly speaking, the setting you want (rather confusingly) to turn TRR off is network.trr.mode = 5.
Use the special URL about:config in Firefox to get to the configuration page.
A setting of network.trr.mode = 0 means “use whatever is the default” – right now that sets TRR off, but if Firefox ever changes its mind, so will you.
AFAIK the settings are:
0 – Default. Firefox’s choice: currently sets DNS on and TRR off. (Right now like 5, but not because *you* said so.)
1 – Fastest. Do TRR and DNS together and use the first reply. (Worst of both worlds.)
2 – Fallback. Do TRR but then do DNS if it fails.
3 – TRR only. Set TRR on and DNS off.
4 – Testing. Use DNS but do TRR as well to compare speed and accuracy.
5 – DNS only. Set DNS on and TRR off.

17 minutes of downtime in a year is still above 99.99% of uptime. That’s better than any ISP DNS. Please don’t poison the list of arguments with weak points like these. I don’t like the option of Cloudflare DNS, but in my opinion it’s better than the alternatives.

Comments are closed.

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!