User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

I tried to disable DoH following several instructions (e.g. https://support.mozilla.org/de/kb/firefox-dns-%C3%BCber-https#w_deaktivierung-von-doh) but firefox always ignores my configuration and seem to use DoH regardless.

Environment:
Ubuntu 18.04 LTS Desktop with Cinnamon
LAN with pihole gateway

Blocked test domain is xnxx.com
$ dig xnxx.com

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> xnxx.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54578
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;xnxx.com. IN A

;; Query time: 38 msec
;; SERVER: 192.168.XXX.YYY#53(192.168.XXX.YYY)
;; WHEN: Sat Apr 04 17:23:45 CEST 2020
;; MSG SIZE rcvd: 37

$ host xnxx.com
Host xnxx.com not found: 3(NXDOMAIN)

$ dig use-application-dns.net

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> use-application-dns.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63890
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;use-application-dns.net. IN A

;; Query time: 39 msec
;; SERVER: 192.168.XXX.YYY#53(192.168.XXX.YYY)
;; WHEN: Sat Apr 04 17:26:41 CEST 2020
;; MSG SIZE rcvd: 52

I tested
network.trr.mode=0
and
network.trr.mode=1

Actual results:

Firefox always resolves xnxx.com brings up the web page.

Expected results:

Firefox may not resolve the domain and must display the error message "The website is not available"

I also tested
network.trr.mode=5
and with an Windows 10 installation of Firefox but had the same issue.

It's not clear to me keeping this bug secret serves any purpose; it's not a security flaw that is exploitable by an attacker - purely an issue about preferences not being honoured (setting prefs is not something an attacker can normally do...). Dragana, can/should this be opened up?

In my opinion, it is not only a pity or poor, if firefox disregards its own configuration in this way.

I consider it essential that software works as documented and recommended by the manufacturer. If not, in my opinion this is per se a massive security breach. This is especially true at such a sensitive interface.

I see security issues when employing DoH with regards to malware distribution and phishing attacks (they can hide all the more comfortably in an HTTPS data stream). It’ll be all the easier to spoof and redirect valid domains to malware sites, being indistinguishable within the browser, all possible by shifting DNS from a network to a client-side feature. Security-wise, DoH will turn out to be a painful experience for our orginazation and the privacy of all users instead of protecting their privacy. It will force admins and organizations to invest in deep package inspection or similar technologies.

By the way in the meantime I also tested firefox 74.0.1. The problem is also present there.

I would like to understand this better. This should not happen. Trr modes 0 and 5 (actuually any number except 2 and 3) should disable DoH.
It may be that we are getting a response from the cache. I know we had a bug where we served dns response from cache that where resolved by TRR even if TRR was turn off at the moment of the second request. That was fixed.
You can look what we have in Firefox cache by visiting about:networking#dns

Can you make a http log:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

This is not a security issue, we may have a but that we server request from cache resolved by Trr even if TRR is disabled. TThe user has to turn on TRR in the session o make it work. This is not exploytable.

Valentin, can you take a look at the issue?

(In reply to Christian Roszak from comment #0)

$ dig use-application-dns.net
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63890
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Note that blocking this domain does nothing unless DoH was enabled automatically for you, which it seems it wasn't.

A log would be very helpful.
It may be that DoH is really disabled, but you're loading the page from the cache.
Could you also try with a new profile? https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Multiple_profiles

Needinfo for comments #4 and #5 for an http log / checking of whether this is related to caching and/or if this is reproducible in a clean profile.

(In reply to Christian Roszak from comment #3)

In my opinion, it is not only a pity or poor, if firefox disregards its own configuration in this way.

Absolutely, broken is broken. Gijs was not dismissing this as a bug, but was trying to figure out if the costs imposed by hiding it as a "vulnerability" (limits who can work on it) are worth it. I agree w/him that we can treat this as a public bug.

Hi Christian, what's the status of this bug? Did you find a workaround? Do you need help in gathering the logs? Thanks!

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)