Headache for UK ISPs as Firefox Adopt DNS Over HTTPS by Default
Broadband ISPs and the Government look set to clash with Mozilla after the internet technology developer announced that it would move forward with its earlier proposal to enable DNS-over-HTTPS (DoH) by default in their popular Firefox website browser, albeit with tweaks to respect ISP network-level internet filters.
We’ve covered this quite a lot before (here and here), so here’s a shortened recap. At its core, DoH is all about protecting user privacy and making internet connections more secure (much like HTTPS has done for websites). As a result DoH – as well as similar solutions like DoT – are often praised by the wider internet community and its support base is growing.
However major UK broadband ISPs and politicians are concerned that large-scale third-party deployments of DoH, which encrypts DNS requests (today most DNS request are still unencrypted) using the common HTTPS protocol for websites (i.e. turning IP addresses into human-readable domain names like ISPreview.co.uk and back again), could disrupt their ability to censor, track and control various internet / account services (parental controls etc.).
NOTE: It’s always been possible to optionally use a different DNS provider from the one deployed by your ISP (Google Public DNS, OpenDNS etc.), although earlier this year Mozilla hinted that it was considering the possibility of enabling DoH by default.
Obviously doing this on a major browser like Firefox would be a significant change, one that has already caused both ISPs and the Government some concern. At one point even resulted in the UK Internet Service Providers Association (ISPA) labeling Mozilla as an “Internet Villain“, although this was promptly withdrawn following a huge backlash (here). Nevertheless, it now appears as if Mozilla will be moving ahead with their proposal.
Selena Deckelmann, Mozilla, said:
“In 2017, Mozilla began working on the DNS-over-HTTPS (DoH) protocol, and since June 2018 we’ve been running experiments in Firefox to ensure the performance and user experience are great. We’ve also been surprised and excited by the more than 70,000 users who have already chosen on their own to explicitly enable DoH in Firefox Release edition. We are close to releasing DoH in the USA, and we have a few updates to share.
After many experiments, we’ve demonstrated that we have a reliable service whose performance is good, that we can detect and mitigate key deployment problems, and that most of our users will benefit from the greater protections of encrypted DNS traffic. We feel confident that enabling DoH by default is the right next step. When DoH is enabled, users will be notified and given the opportunity to opt out.”
One positive bit of news for ISPs is that Mozilla plans to mitigate at least some, albeit by no means all, of their concerns with a few tweaks to their proposed approach. The tweaks are aimed at supporting ISPs that deploy managed networks and parental controls (e.g. DNS based network-level filtering/website blocking).
Summary of Mozilla’s Approach to DoH by Default
At a high level, our plan is to:
— Respect user choice for opt-in parental controls and disable DoH if we detect them;
— Respect enterprise configuration and disable DoH unless explicitly enabled by enterprise configuration; and
— Fall back to operating system defaults for DNS when split-horizon configuration or other DNS issues cause lookup failures.
We’re planning to deploy DoH in “fallback” mode; that is, if domain name lookups using DoH fail or if our heuristics are triggered, Firefox will fall back and use the default operating system DNS. This means that for the minority of users whose DNS lookups might fail because of split horizon configuration, Firefox will attempt to find the correct address through the operating system DNS.
In addition, Firefox already detects that parental controls are enabled in the operating system, and if they are in effect, Firefox will disable DoH. Similarly, Firefox will detect whether enterprise policies have been set on the device and will disable DoH in those circumstances. If an enterprise policy explicitly enables DoH, which we think would be awesome, we will also respect that.
Options for Providers of Parental Controls
We’re also working with providers of parental controls, including ISPs, to add a canary domain to their blocklists. This helps us in situations where the parental controls operate on the network rather than an individual computer. If Firefox determines that our canary domain is blocked, this will indicate that opt-in parental controls are in effect on the network, and Firefox will disable DoH automatically.
This canary domain is intended for use in cases where users have opted-in to parental controls. We plan to revisit the use of this heuristic over time, and we will be paying close attention to how the canary domain is adopted. If we find that it is being abused to disable DoH in situations where users have not explicitly opted in, we will revisit our approach.
The last point about the feature being “abused to disable DoH in situations where users have not explicitly opted-in” could conflict with some of the filtering systems used by ISPs in the United Kingdom, although at present consumers do have the option to disable Parental Controls but the upcoming mandatory porn block (age verification) could be more contentious.
Apparently Mozilla will start rolling out this change gradually “to a small percentage of users” from later this month, albeit initially only in the USA. The not-for-profit company will then take stock of how their initial deployment is going before expanding it out to be a much larger audience. Users of Firefox can of course manually enable this feature today if they so wish.
Most people often trust Mozilla more than ISPs to act within their best interests, although it’s worth remembering that the DoH servers may not be UK based (hopefully they do set one up for the UK – given the different data laws between countries). ISPs may also be concerned that if something goes wrong with Firefox’s DoH system then they will be the ones who get the blame via support calls