Firefox, DNS over HTTPS, and us

September 18, 2019

The news of the time interval is that Mozilla will soon start rolling out DNS over HTTPS for US users, where by 'rolling out' Mozilla means 'enabling by default'. To their minimum credit, Mozilla says that they will explicitly notify people of this change and give them the opportunity to opt out. I hope and assume that this will work much like how Mozilla rolled out various tracking protection measures, including with how thoroughly informative that was.

(Clearly notifying people and giving them the chance to opt out is the obvious right thing to do, but Mozilla's track record on doing the obvious right thing is somewhat mixed.)

Since we're not in the US, this doesn't immediately affect people here; however, I have to assume that Mozilla is going to start rolling DNS over HTTPS out more broadly than just the USA. Given things like GDPR, Mozilla may not push this to Europe any time soon, but there probably aren't many roadblocks for rolling it out in Canada. My overall views on this remain unchanged; there are tradeoffs in either direction, and I have no idea what the right choice is in general.

For my department in particular, Firefox switching to DNS over HTTPS presents a potential problem because we have a split horizon DNS setup where some names resolve to different IPs internally than they do externally. According to Mozilla's blog post, the Firefox DoH implementation has some heuristics to detect a split horizon DNS environment, but from the vague descriptions we have so far it's not clear if they would reliably trigger for our users. If people here wind up with Firefox configured to use DNS over HTTPS and Mozilla's split horizon DNS heuristics don't trigger, they won't be able to connect to some of our hosts. We could theoretically say that this is people's fault in the same way that setting their machine to always use one of the public resolvers is, but this is the wrong answer, since Mozilla will have made this setting for them.

Mozilla currently supports a way for networks to explicitly disable DNS over HTTPS, by making your local resolver return NXDOMAIN for a canary domain. This is easy to do in Unbound, which we use on our local OpenBSD resolvers (see here or here). We could preemptively deploy this, but I tentatively think that we should wait to see if the Firefox split horizon detection heuristics work in our environment. Working heuristics would be the best answer for various reasons (including that Mozilla may find too many people abusing the canary domain and start paying less attention to it).

For work, there's probably no point in adding DNS over HTTPS to our local resolving DNS servers, even once it's supported on the OpenBSD version of Unbound. As far as I know, people here would have to specifically configure their Firefox to talk to our servers, and then their configuration would break when they moved outside of our network and could no longer reach our resolving DNS servers.

For my own personal use, I may eventually add DNS over HTTPS support to my resolving Unbound instances, because apparently DoH is the only way to get encrypted SNI. Unfortunately it also apparently normally requires DNSSEC, so unless I can get my Unbound to lie about that (or Firefox to not care), I may be out of luck. I do wish I could tell Firefox that a resolver on localhost was trusted even without DoH, but I suspect that I can't.

(This does raise long term issues about encrypted SNI support for our users, but perhaps in the long term people will come up with answers. Hopefully ones that don't involve DNSSEC.)

Comments on this page:

IMHO I think it is a good idea to start offering DoH and DoT on internal recursive servers because the more places that have it, the more likely that software makers and OSes will will point to it. One claimed problem that is causing Mozilla to override OS defaults is that they say no one is doing anything to help move encrypted DNS forward, so they've deigned it necessary to take matters into their own hands.

There are proxies (packages available) that all one to add the functionality without changing / reconfiguring software:

A good talk and a panel discussion on DNS over HTTPS considerations:

With regards to blocking "", note that this will break DNSSEC.

The normal path for a DNS lookup is "." -> net -> use-application-dns. At every "->" the NS records are sent over, and these are signed.

So when the "." replies back with the NS records on where to talk to "net", and they also have an RRSIG. And when "net" send over the NS records on how to talk to "use-application-dns", they are also signed—but those are now taken over and an NXDOMAIN is faked. But there is no signature on that response (or more properly there is no NSEC(3)).

So one can either have proper DNSSEC validation or block DoH, but not both.

What Mozilla should have probably done is use a host record; something like (say) This way you're not breaking the DNSSEC response of going from net to application-dns. Further, there could have been things like "use-doh" and "use-dot" so that DNS operators could signal the use (or not) of teach of those protocols.

It would have been nice if Mozilla talk to the DNS folks (e.g., DNS-OARC), but there is no evidence that they did AFAICT.

By cks at 2019-09-19 16:17:55:

The problem I see with supporting DoH and/or DoT on our internal resolvers is that as far as I know, there's no way to advertise support for it in a way that lets it be automatically configured and de-configured as people move between networks. It's routine for people here to migrate machines between our networks and other ones, so that has to work seamlessly. If it requires manual work to switch to our DoH server and then switch away again, approximately no one will do it and we might as well not implement it.

As far as DNSSEC goes, we are very unlikely to enable it on our internal resolvers after my experiences with it on my own machines. The very last thing we want is for our users to run into mysteriously unresolvable DNS names. Breaking DNSSEC for the canary domain is not a problem.

There is a draft available for bootstrapping/discovering DoT and DoH servers:

In the short term I think that OSes will simply take what's given from DHCP or in resolv.conf(5) and simply try to connect securely.

Written on 18 September 2019.
« Converting a Go pointer to an integer doesn't quite do what it looks like
TLS server certificate verification has two parts (and some consequences) »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Sep 18 23:37:31 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.