1663408 - Some DNS lookups are not done over DoH

Status: RESOLVED INCOMPLETE

(Core :: Networking: DNS, defect, P3)

Description

[Gian-Carlo Pascutto [:gcp]]

STR (not 100% reliable I suspect, and obviously never outside my network!)

1. Have DoH enabled.
2. Open new private window
3. Visit thepiratebay.org

Expected:

End up on thepiratebay.org

Actual (sometimes):

End up at http://networkmsg.telenet.be/blocked/fccu/

The reason I end up at the redirect is that my (Belgian) ISP force-redirects the domain to a government warning site. But as I am using DoH, they should never have gotten the opportunity to intercept the request. That they did means we are NOT using DoH in some cases.

Repeating the request to thepiratebay.org some time afterwards brings me to the site, without hitting the government warning page. So DoH did work at the second attempt.

Comment 1

[Valentin Gosu [:valentin]]

Hi, this is due to how our TRR is implemented - we fallback to DNS if for some reason the lookup failed when using DoH.
There are lots of reasons this could happen:

• timeout - if the lookup is taking too long (>1.5 s)
• failed connection - we are unable to establish a connection to your chose TRR provider
• failed lookup - TRR request worked, but the server didn't return a response - we still fallback to native DNS

But most likely this is caused by the fact that when starting up, we don't start using DoH until it is actually ready to use (confirmed).
You can verify if it is the case by going to about:config and setting the network.trr.confirmationNS pref to skip.
Now the DoH connection should always be used first. It still falls back to DNS, but there is no confirmation process.
Please let me know if this helps.

Comment 2

[Gian-Carlo Pascutto [:gcp]]

But most likely this is caused by the fact that when starting up, we don't start using DoH until it is actually ready to use (confirmed).

Would this be immediately after startup, or does opening up a private window "reset" this?

Comment 3

[Valentin Gosu [:valentin]]

It may happen at various times if the DoH connection drops.
The main reason you're seeing it when opening a private window is that it uses a separate DNS cache to prevent privacy leaks.
Let me know if it keeps happening. In that case I'll ask you to capture some logging when it does. Thanks!

Comment 4

[Gian-Carlo Pascutto [:gcp]]

It has happened before but not so often that I happen to have a log when it does.

My concern is the following sequence:

a) I open a private window
b) I immediately enter the URL I want to visit

Now, because of the "separate DNS cache", the DoH isn't initialized(?) and the query goes over the normal network. This is quite undesirable if one has just opened a private window.

Comment 5

[Valentin Gosu [:valentin]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #4)

Now, because of the "separate DNS cache", the DoH isn't initialized(?) and the query goes over the normal network. This is quite undesirable if one has just opened a private window.

The DoH connection could be down at any point, but due to using a separate cache for PB it will be more obvious since that domain will not be in the DNS cache.
This is assuming that we don't have a bug somewhere that is causing this. In which case logs will be required. [1]

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging#Logging_HTTP_activity_by_manually_setting_environment_variables

The environment variable contains a rotate:[SIZE] parameter that makes sure we don't exceed the disc capacity. Just make sure to shut down Firefox after you reproduce.

Comment 6

[Gian-Carlo Pascutto [:gcp]]

I did some tests with quickly opening a private window after a clean startup, but could not reproduce the issue. I'm going to assume these were network hiccups (and thus the behavior seen is expected with the default settings), can still reopen if I see anything suspicious.

Comment 7

[Valentin Gosu [:valentin]]

Good to know. Thanks for reporting. We're currently considering whether to make skip the default for TRR. It might take a while for the change to happen.

If you see this issue happening again, please let me know. Cheers!

Comment 8

[Gian-Carlo Pascutto [:gcp]]

I just hit this again, at a moment when I'm reasonably sure the network was working fine, after having just opened several tabs.

I guess I'm going to have to run with logging enabled for a longer time to understand how exactly this triggers, but at this point, I've seen this at least 3 times (and it's not like there's a lot of blocked pages like that!), which means Firefox must very regularly "leak" DNS information. After all, I wouldn't even notice the leakage on normal, non-blocked pages, which are like 99% of my browsing activity.

Comment 9

[Valentin Gosu [:valentin]]

Right now we don't have enough info to address this issue.
If you are still able to reproduce it, I'd appreciate it if you could capture some logs when it happens using these instructions:
https://firefox-source-docs.mozilla.org/networking/http/logging.html

Thanks!