Cerca nel supporto

Attenzione alle mail truffa. Mozilla non chiederà mai di chiamare o mandare messaggi a un numero di telefono o di inviare dati personali. Segnalare qualsiasi attività sospetta utilizzando l'opzione “Segnala abuso”.

Ulteriori informazioni

Questa discussione è archiviata. Inserire una nuova richiesta se occorre aiuto.

Preventing DoH rollout on our network?

more options

The day that DNS-over-HTTPS is released seems to come closer which has me worried. We run Firefox on 100+ machines for NGO's, most off the people use it as it is the default browser.

We run internal DNS, as far as I can tell DoH will break this, internal DNS won't resolve in Firefox any longer. Is there a way to prevent DoH rollout on our network. Other than blocking updates or dropping Firefox all together.

It will be a bad day when this rolls out and users start calling, so I would love to prevent it :)

Many thanks for any insights on this in advance.

The day that DNS-over-HTTPS is released seems to come closer which has me worried. We run Firefox on 100+ machines for NGO's, most off the people use it as it is the default browser. We run internal DNS, as far as I can tell DoH will break this, internal DNS won't resolve in Firefox any longer. Is there a way to prevent DoH rollout on our network. Other than blocking updates or dropping Firefox all together. It will be a bad day when this rolls out and users start calling, so I would love to prevent it :) Many thanks for any insights on this in advance.

Modificato da peat588 il

Tutte le risposte (20)

more options

What did your IT say about this?

more options
more options

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.

more options

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
)

more options

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

more options

I will move this question to Firefox for Enterprise.

more options

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?

more options

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?

more options

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/

Modificato da jscher2000 - Support Volunteer il

more options

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.

more options

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.

more options

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 ;)

more options

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.

more options

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.

more options

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 options

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

more options

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 ;)

more options

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.

more options

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