Affected versions

• Firefox 72.0a1 (BuildId:20191119043902).

Affected platforms

• Windows 10 64bit.
• Ubuntu 18.04 64bit.
• macOS 10.13

Preconditions

• Configure a local DOH server.
• Set network.trr.uri to point out the DOH server.
• Set network.trr.mode to 2.

Steps to reproduce

1. Access a domain that is part of your local network.

Expected result

• Requests are not reaching the DOH server.

Actual result

• Requests are reaching the DOH server.

Regression Range

• Will investigate asap.

Notes
Attaching a log file.

The reason for this bug is this part of the code. It is easily noticeable in the logs.
When blacklisting a domain we send a NS request for the name. We should also check if it's excludedFromTRR.

Emil, could you retest this with a recent build >=25 nov and upload the logs if it still happens?
Thanks a lot!!

Hi Valentin, sorry for the late response.

I retested this on Fx 72.0a1 (BuildId:20191126093448) on both Ubuntu and Windows 10 and noticed the following:

On Ubuntu the DNS suffix for that domain is successfully parsed and displayed inside the about:networking#dns page without the need to restart the network connection... but after performing a request for that domain it still leaks inside the DOH server. (even though the about:networking#dns page displays that the request was not handled via TRR).
Note: I've found out that only if the network connection is restarted, the request is no longer leaked to the DOH server (searched different webpages that are on that particular domain).

Attaching a log for this^.

On the other hand, on Windows it seems that I need to force a network re connection for the DNS suffix to be parsed and displayed inside the about:networking#dns page...So I guess that's why I don't see the leakage on my DOH server.

After further investigating this I've found out that the requests which are made for the domain that is part of my local network are leaked inside the DOH proxy server even though they should be resolved via DNS (about:networking#dns displays that each request for pages on my local domain have TRR value to false).

Setting a DNS suffix for my local domain seems to solve this but with the mentions from Comment 3.

Also, this behavior is reproducible on macOS 10.13 as well.

(In reply to Emil Ghitta, QA [:emilghitta] from comment #3)

Created attachment 9111662 [details]
log2

Hi Valentin, sorry for the late response.

I retested this on Fx 72.0a1 (BuildId:20191126093448) on both Ubuntu and Windows 10 and noticed the following:

On Ubuntu the DNS suffix for that domain is successfully parsed and displayed inside the about:networking#dns page without the need to restart the network connection... but after performing a request for that domain it still leaks inside the DOH server. (even though the about:networking#dns page displays that the request was not handled via TRR).

So, looking at the logs, what caught my eye was:

2019-11-26 17:00:03.685111 UTC - [Parent 6822: Main Thread]: D/nsHostResolver Checking if host [jira.softvision.ro] is blacklisted
2019-11-26 17:00:03.685158 UTC - [Parent 6822: Main Thread]: D/nsHostResolver TRR::SendHTTPRequest resolve jira.softvision.ro type 1

However, considering that we do check if it's excluded, it seemed like the suffix list wasn't properly parsed at this point, which turns out to be the case.
If I only look in the logs after this line:
2019-11-26 17:01:03.100364 UTC - [Parent 6822: Main Thread]: D/nsHostResolver TRRService adding softvision.ro to suffix list
then all the requests for softvision.ro domains are properly excluded from TRR.

In the logs there is one minute until the suffix list is installed, which will probably be improved by bug 1590528.
However, we might still have a small race on our hands:

The problem here is likely this:

1. We start Firefox
2. The Link Monitor thread (nsNotifyAddr) is getting the suffix list from the platform
3. Firefox is loading its usual tabs, history, etc... it issues the TRR requests
4. The suffix list is computed and installed into the TRRService
   Result: we still have TRR requests that should not be there.

I don't think that this is a regression. This issue seems to be reproducible with builds from 2018 as well. Removing the regressionwindow-wanted keyword.