User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

I had ESNI configured together with Secure DNS and DNSSEC, host dns.digitale-gesellschsaft.ch. Up to release firefox 71.0, everything worked as expected. Test site https://www.cloudflare.com/ssl/encrypted-sni/ reported green lights (except for the Secure DNS test which only becomes green with the cloudflare server configured as trr.uri).

The today's update to firefox 72.0.1 broke that functionality. I could not get it to work neither with google, nor cloudflare or digitale-gesellschaft servers.

I downgraded back to firefox 71.0 and started with the --allow-downgrade command line option to load the old configuration, and everything was working again.

Actual results:

Update to 72.0.1 apparently breaks ESNI. Downgrade to 71.0 brings it back again.

Expected results:

Upgrade should not break configured behaviour.

It would help if you can find the exact regression range.
https://mozilla.github.io/mozregression/quickstart.html

before firefox update:
i had enabled ESNI from about:config and Dns-over-HTTPS from 'Network Settings' in about:preferences

after update I checked and enabled esni again, i.e. network.security.esni.enabled set to true.

then I saw this by chance and checked it again on https://www.cloudflare.com/ssl/encrypted-sni, it showed 'Secure DNS' & 'Encrypted SNI' was not active. Then I reloaded the same page in incognito and it showed all as expected; DNSSEC is not setup, so all good there. Checked the page again and all 3 were green.

So I think "Upgrade should not break configured behaviour." sums it up nicely.

offtopic: thanks for mozregression link that it sounds like a great tool. Wish I could use it to help. It works on Windows too.
mozregression review : its more productive to not ask anyone to use tools like that, its way too complicated.
can't use it on Windows, its not safe to use on windows, from what I tested. and glanced at the source code, my wild, wild guess was right. for e.g.- see "https://github.com/mozilla/mozregression/blob/gui-0.9.44/gui/wininst/wininst.nsi"

obviously, you will need a internet connection that can download all the firefox nightly builds. My wild guess is you'll need at least 30Megabit/s speeds with more than 1 Gigabyte/day data-cap.

off-topic or assessing impact:
How would the users on Firefox 72 be notified that they should check that the upgrade went as planned and there are no subtle, hidden issues with their privacy-protecting browser. I hope the answer is not https://lists.mozilla.org/listinfo/announce

I trust most users won't (or be able to) report breakage unless reality changed. So please take that into consideration. I would exclude ESNI from this but some blogs posts made it very easy to do so, one was cloudflare's.

here's my screenshot on firefox 72 after fixing the esni.enabled configuration:-
can't paste to upload it.

I guess status for this issue can be updated now?

I'll tap out for now, so all the best.

I would like to agree to everything m23retyer was saying. I experience the issue on the installation at work, and I cannot download gigabytes of builds there just to test. I was aware of the issue because I was currently viewing a page that will be blocked by our proxy and was surprised to find it blocked again after upgrade and restart of firefox. So, it was pure happenstance I found there is an issue at all.

This is a security issue as well and of high impact for people relying on secrecy. That such a security feature is disabled without notice during update, and even with the correct settings still present, makes it especially critical.

I have to add that this does not affect my home installation, where the feature still works. Maybe it has something to do with using that over proxxy. I did not yet test that incognito mode which m23retyer claims would continue working.

Just verified again that upgrading to 72.1 breaks the functionality at my working place, and downgrading to 71.0 without changing anything in configuration restores it again. Private tabs do not work in 72.1 either.

Only difference that I know about to my working 72.1 home installation is the provider, and the proxy settings.

Dragana, just from the top of your head - is this expected or does it need a deeper look?

I just verified that the issue is still there with the 72.0.2 update. Downgraded back to 71.0 => fixed.

$before = 'network.security.esni.enabled = True; before update; on Firefox 72.0.1'
$after= 'network.security.esni.enabled = True; after update; on Firefox 72.0.2'

to repeat, 72.0.1 -> 72.0.2, did not change network.security.esni.enabled , updated by going to Help>About Firefox

didn't check 71.0->72.0.2, I just want

off-topic: GitHub-flavored markdown along with a helpful link to https://guides.github.com/features/mastering-markdown/ its awesome! and thanks a lot!

OK, I just did an additional check and finally resolved my problem. Apparently, 72.0 beta introduced some new parameters accessible via about:config, which are set to false by default and which change the behaviour significantly:

network.trr.enable_when_nrpt_detected
network.trr.enable_when_proxy_detected
network.trr.enable_when_vpn_detected

I figured that in my case, setting network.trr.enable_when_nrpt_detected to true enables ESNI and DNS over HTTPS again with the new version. Problem solved. Cloudflare site now reports DNSSEC and TLS 1.3 green as well.

I still find it strange if not to say dangerously that such a change is introduced silently.

So, in bug 1565022 and more generally in bug 1512255 we introduced some checks to prevent the use of TRR when it might cause issues with split horizon DNS. It seems the reporter triggered these checks, which disabled TRR for them.
As a result, ESNI also stopped working (at the moment ESNI is completely dependent on having TRR turned on).