What did your IT say about this?

I am IT

You can do this via a policies.json file.

• https://github.com/mozilla/policy-templates/blob/master/README.md#dnsoverhttps
• https://support.mozilla.org/en-US/kb/customizing-firefox-using-policiesjson

Ok, that could work, thanks. I would have to figure out how to deal with laptops we don't have central management for those yet.

See also:

• Bug 1484843 - Create a policy to disable DNS over HTTPS

(please do not comment in bug reports
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html)

Ok, I'll keep an eye on that, I'll start testing next week. Thanks again.

I will move this question to Firefox for Enterprise.

One thing I just thought off, our WIFI vlan has internal dns for certain internet facing web services we host on-site. People connect devices we do not control to that.

Is there some resolution for this use case built in the DoH implementation?

I don't think DNS-over-HTTP-by-default is imminent for the Extended Support Release. I'm not even sure there will be any change in Firefox 64 -- the last blog post makes it sound like there is still plenty of testing to do:

https://blog.mozilla.org/futurereleases/2018/11/27/next-steps-in-dns-over-https-testing/

Or are you concerned that users might enable it themselves and you want to block that?

peat588 said

We run internal DNS, as far as I can tell DoH will break this, internal DNS won't resolve in Firefox any longer.

DNS-over-HTTP, also known as "Trusted Recursive Resolver" or trr, has several modes. One of them is exclusive and won't fall back to local resolution, but the one I think is most likely to be used will check the remote provider first and then fall back to local resolution. If you need to override remote server addresses, then that won't work for you, but if your internal server names are not legal domain names (e.g., intranet, mountainview-01, etc.), that would still work.

If you want to experiment:

EDIT: THIS IS FOR FIREFOX 62+, NOT FOR ESR 60

(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful or accepting the risk.

(2) In the search box above the list, type or paste trr and pause while the list is filtered

(3) Double-click the network.trr.mode preference to display a dialog where you can enter the desired value from the following list, then click OK

• 0 - local only, TRR off by default (current setting)
• 1 - query TRR and local, use first available
• 2 - query TRR first, fallback to local (most logical future setting)
• 3 - query TRR only, do not use local (most private?)
• 4 - use local but test TRR performance (temporary??)
• 5 - local only, TRR off by user choice (won't be overridden??)

From: https://daniel.haxx.se/blog/2018/06/03/inside-firefoxs-doh-engine/

Users won' t enable it them self however there is a high change DoH will get enabled by default in the near future. In the non ESR versions users run at least.

Once this happens the internal services will not work on our network with FF. Users will not understand why even if I explain.

Say they want to connect to our Nextcloud using their own device on our WIFI with FF. It will not work with DoH enabled, they'll rather revert to Google Drive instead of disabling DoH. It is a constant struggle to get and keep users on our open source internal services like NC. Something like it not working on their device will set this back.

For this reason I'm looking for a solution preventing the above hoping the FF dev' s considered our use case. I won't be able to catch up in time once DoH gets rolled out.

peat588 said

Say they want to connect to our Nextcloud using their own device on our WIFI with FF. It will not work with DoH enabled, they'll rather revert to Google Drive instead of disabling DoH. It is a constant struggle to get and keep users on our open source internal services like NC. Something like it not working on their device will set this back.

Hmm, do you manage the Firefox installation on the user's own device? If not, I don't think there is a workaround for your scenario unless you block connections to CloudFlare DNS through your wi-fi routers.

As a data point, Firefox "Nightly" -- future Firefox 65 -- currently has

network.trr.mode => 2 (TRR first, fall back to local)

I think that is the most likely scenario, and you might want to test it on your wi-fi using Firefox 63 or higher and see what happens.

I'm looking into blocking DoH on our firewall, that could work. It is hard because it is https and a moving target.

Otherwise we might start actively discouraging Firefox use, also because it could violate European privacy laws. I might be able to block FF on our WIFI by implementing a access page checking the user agent or something.

These things can limit the damage for now, at least until Google starts implementing DoH in Chrome ;)

Well, maybe you're right to be in panic mode on a Saturday morning, but maybe not.

When I tested

network.trr.mode => 2 (TRR first, fall back to local)

on the company LAN earlier this year, the fallback for unresolved local server hostnames worked perfectly. When I test Nightly today on VPN, the fallback still works smoothly.

If the fallback does not work when you test it in your environment, I think the developers should be alerted so that can be debugged and fixed ASAP.

The problem is that the domain does resolve using DoH, but to the external ip not internal as it has to on our WIFI vlan. So it will just time out because it cannot connect to the external ip.

I'll run a test and file a bug report, however I believe it cannot be fixed because of the fallback mechanism.

I see. If Firefox gets an IP address from the first resolver, it has no reason to fall back to the local resolver.

There doesn't seem to be a preference value for trying the local resolver if the first IP address is unresponsive.

Timing out takes a long time, so it's not optimal to have DNS resolution wait. Is there any unique HTTP status code you could return to provide a hook for that? I don't immediately see a suitable one in https://en.wikipedia.org/wiki/List_of_HTTP_status_codes. Maybe they can come up with another one.

More problematic when the record does resolve with DoH but with the wrong ip for the local network because of NAT.

I' ve filed the bug report after testing if DNS overrides are ignored, they are for me.

I'm pretty sure the devs know about the issue but it might help.

https://bugzilla.mozilla.org/show_bug.cgi?id=1511643

On a side note I realized a stop gap measure to block DoH in FF is by overriding mozilla.cloudflare-dns.com on my DNS server ;)

The jury is out, wontfix regarding the bug report, I'll go ahead and implement the policies and blocking measures.

We might move to remove FF of our computers and block it from WIFI somehow, I'll have to think about that.

If someone has other suggestions on how to work with this, that would be greatly appreciated.

Just a note that OpenDNS customers will have the option to block the feature through their management console:

https://support.umbrella.com/hc/en-us/articles/360001371526-Firefox-and-DNS-over-HTTPS-default