Disabling Firefox's automatic switch to DoH

[RMerlin]

In the coming weeks, Mozilla will be enabling DoH by default in Firefox (starting with US-based users). While it can still be manually enabled/disabled, this opt-out behaviour is unacceptable IMHO. For starter, it means that by default, your browser will ignore whatever configuration you have made on your network (if using DNS over TLS at the router level, for example).

Firefox looks for a certain canary domain to disable that automatic feature when using, for example, a parental or ad filter provided by your DNS servers.

For now, you can use that canary domain to prevent that automatic DoH enabling, by creating a /jffs/configs/dnsmasq.conf.add file, with the following entry:

server=/use-application-dns.net/

Then, restart dnsmasq:

service restart_dnsmasq

I am currently evaluating how to implement this in the firmware. The initial tentative plan is to have a new switch to enable that "Block Firefox automatic DoH usage", with the following options:

0-Enable killswitch if using DNSPrivacy (the default)
1-Enable killswitch
2-Diasble killswitch

The default value would be to enable the killswitch if you use DNSPrivacy (i.e. DNS over TLS), to ensure that browsers won't automatically bypass it.

This is still all being evaluated on my end.

 

[heysoundude]

In the coming weeks, Mozilla will be enabling DoH by default in Firefox (starting with US-based users). While it can still be manually enabled/disabled, this opt-out behaviour is unacceptable IMHO. For starter, it means that by default, your browser will ignore whatever configuration you have made on your network (if using DNS over TLS at the router level, for example).

Firefox looks for a certain canary domain to disable that automatic feature when using, for example, a parental or ad filter provided by your DNS servers.

For now, you can use that canary domain to prevent that automatic DoH enabling, by creating a /jffs/configs/dnsmasq.conf.add file, with the following entry:

server=/use-application-dns.net/

Then, restart dnsmasq:

service restart_dnsmasq

I am currently evaluating how to implement this in the firmware. The initial tentative plan is to have a new switch to enable that "Block Firefox automatic DoH usage", with the following options:

0-Enable killswitch if using DNSPrivacy (the default)
1-Enable killswitch
2-Diasble killswitch

The default value would be to enable the killswitch if you use DNSPrivacy (i.e. DNS over TLS), to ensure that browsers won't automatically bypass it.

This is still all being evaluated on my end.

DoH is on Brave's roadmap as well; might I suggest "Block browser auto DoH usage"?

 

[RMerlin]

DoH is on Brave's roadmap as well; might I suggest "Block browser auto DoH usage"?

Is Brave going to make it opt-in, or opt-out? That's the main difference there.

It will also depend on whether they will support the same canary domain as Mozilla.

 

[heysoundude]

I'm not sure...but if they implement DoH, it would probably be opt-out because of their privacy focus

 

[RMerlin]

I'm not sure...but if they implement DoH, it would probably be opt-out because of their privacy focus

That might be debatable. Opt-out would mean that, by default, they send all your DNS queries to a server of THEIR choice...

 

[heysoundude]

I’ll see if I can dig up some more info on their plans for you from their community forum or github

EDIT: forum lead to github -
https://github.com/brave/brave-browser/issues/1864


Sent from my iPhone using Tapatalk

 

[ColinTaylor]

For now, you can use that canary domain to prevent that automatic DoH enabling, by creating a /jffs/configs/dnsmasq.conf.add file, with the following entry:

server=/use-application-dns.net/

I use the following code instead. The dnsmasq man page says the commands are equivalent for this use case. I don't know if there are any subtle differences but this seems more appropriate and at least gets rid of the slightly annoying "using only locally-known addresses for domain use-application-dns.net" message.

address=/use-application-dns.net/

 

[ColinTaylor]

Quite a good summary of the issues here: https://tools.ietf.org/id/draft-reid-doh-operator-00.html

EDIT: Just noticed that this draft document expires today! So read it while you can.

 

[RMerlin]

I use the following code instead. The dnsmasq man page says the commands are equivalent for this use case. I don't know if there are any subtle differences but this seems more appropriate and at least gets rid of the slightly annoying "using only locally-known addresses for domain use-application-dns.net" message.

My method was based on a post made by Simon Kelley, the dnsmasq author.

 

[CriticJay]

Awesome, thanks for looking out for your firmwares' users.

 

[ColinTaylor]

Rolling in DoH: Chrome 78 to experiment with DNS-over-HTTPS – hot on the heels of Firefox

Google promises it won't override your choice of DNS provider

https://www.theregister.co.uk/2019/09/10/chrome_78_dnsoverhttps/

 

[MarkRH]

So far in 69 release, 70 beta, and 71 Nightly, DoH has remained unchecked in the Network Settings panel.

 

[rk8531]

DNScrypt already has a fix for it. May I suggest adding it to the Merlin's firmware even though it's not a standard

 

[ColinTaylor]

DNScrypt already has a fix for it.

How does that work? Surely the whole issue is that the client (e.g. Firefox) is bypassing things like DNScrypt on the router. Or have I completely missed the point here?

 

[dave14305]

How does that work? Surely the whole issue is that the client (e.g. Firefox) is bypassing things like DNScrypt on the router. Or have I completely missed the point here?

Looks like the same solution to NXDOMAIN the canary domain.
https://github.com/jedisct1/dnscrypt-proxy/blob/master/dnscrypt-proxy/plugin_firefox.go

 

[ColinTaylor]

How does that work? Surely the whole issue is that the client (e.g. Firefox) is bypassing things like DNScrypt on the router. Or have I completely missed the point here?

EDIT: OK I've just seen the other post here that you responded to. The supposed "solution" is in fact exactly the same thing RMerlin proposed in post #1 (which can be implemented straight away). So there's no need to add DNScrypt instead of just adding one line to a config file.

 

[netware5]

How does that work? Surely the whole issue is that the client (e.g. Firefox) is bypassing things like DNScrypt on the router. Or have I completely missed the point here?

I also have the same question.

BTW I think that due to the recent significant changes in DNS "world" in last years it is a time now to create a sticky post about different options to implement secure DNS in AsusWRT Merlin. The recent Firefox and Chrome move to DoH just demonstrate the need of such guidance. I am sure that many forum users will appreciate the guidance regarding PROS and CONS of different secure DNS options, how to implement them in home network and how to circumvent these, which are enforced by browser vendors like DoH, if the user wish so.

Now searching the forum shows many posts related to that issue. But bringing them in one single sticky post would be very helpful.

 

[HairyA00]

In the coming weeks, Mozilla will be enabling DoH by default in Firefox (starting with US-based users). While it can still be manually enabled/disabled, this opt-out behaviour is unacceptable IMHO. For starter, it means that by default, your browser will ignore whatever configuration you have made on your network (if using DNS over TLS at the router level, for example).

Firefox looks for a certain canary domain to disable that automatic feature when using, for example, a parental or ad filter provided by your DNS servers.

For now, you can use that canary domain to prevent that automatic DoH enabling, by creating a /jffs/configs/dnsmasq.conf.add file, with the following entry:

server=/use-application-dns.net/

Then, restart dnsmasq:

service restart_dnsmasq

I am currently evaluating how to implement this in the firmware. The initial tentative plan is to have a new switch to enable that "Block Firefox automatic DoH usage", with the following options:

0-Enable killswitch if using DNSPrivacy (the default)
1-Enable killswitch
2-Diasble killswitch

The default value would be to enable the killswitch if you use DNSPrivacy (i.e. DNS over TLS), to ensure that browsers won't automatically bypass it.

This is still all being evaluated on my end.

Why not make it an always-on feature? Shouldn't be a reason to configure this; if you're on a network like mine, you should be forced to do what my router says you're going to do. I'm not sure why web browsers think they have the right to manipulate traffic, especially in the case of Google... now ALL your traffic can belong to them if you use Chrome and you can be profiled further. This isn't an increase in security, it's an attack on privacy (at least the way I see it). Not that this point is neither here nor there, but the pi-hole guys aren't even going to give the option; if you're on my network, your DNS traffic does what I say it does: https://github.com/pi-hole/pi-hole/pull/2915

EDIT: Post sounds harsh, I guess I am fired up. It's worth having a 'disable' feature, but it should, as you mentioned, be enabled by default.

 

[Diamond67]

your browser will ignore whatever configuration you have made on your network (if using DNS over TLS at the router level, for example).

What happens if you have some VPN service activated?

I use PIA (Private Internet Access) Client Application with Windows 10. I haven't configured my router to connect to PIA.

When I go to PIA Client App Settings - Network - Network Preferences - Name Servers, and choose for example "PIA DNS", will the DoH of Firefox (or Brave or Chrome or whatever in the future) bypass the PIA DNS as well?

 

[ColinTaylor]

When I go to PIA Client App Settings - Network - Network Preferences - Name Servers, and choose for example "PIA DNS", will the DoH of Firefox (or Brave or Chrome or whatever in the future) bypass the PIA DNS as well?

Theoretically yes, unless the PIA DNS servers implement the same canary test/block described in post #1. Of course the traffic between you and PIA is still being encrypted by the tunnel as before, that hasn't changed.