Consider if we want the telemetry probe at shutdown to respect TRR settings or not
Categories
(Core :: Networking: DNS, task, P3)
Tracking
()
People
(Reporter: valentin, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged][trr][mode3])
As mentioned in Bug 1593873 comment 5 it seems that we are doing a final telemetry probe at shutdown which happens in a different process. [1]
We should consider if this probe should also respect TRR settings. It seems it would be difficult to apply TRR rules to other processes, but that is a technical issue.
Wayne, Nhi, do you have any opinion here?
Comment 1•4 years ago
|
||
Actually, this was broken in Firefox Version 79.0 for Linux which doesn't honor network.trr.mode 3
under any circumstances. It doesn't matter what network.captive-portal-service.enabled
is set to either.
Version 68.11.0esr correctly honors network.trr.mode 3
and will not fall back to local DNS except for domains listed in network.trr.builtin-excluded-domains
.
Suggested test for detecting if network.trr.mode 3
is functioning properly.
- Set DNS local domain to something that is not in
network.trr.builtin-excluded-domains
For example, .home or .lan - Set
network.trr.mode 3
- If Firefox can connect to the local domain,
network.trr.mode 3
is being ignored and the test has failed.
Also, there seems to be some misconception in the Firefox development community as to what protections DoH can actually provide. DoH only provides protection against DNS spoofing (local DNS returning a malicious IP address). DoH does not provide anonymity protection. Please see section DoH doesn't actually prevent ISPs user tracking at https://www.zdnet.com/article/dns-over-https-causes-more-problems-than-it-solves-experts-say/ for a fuller explantion. Note that I think that all other points in this article are either irrelevant or incorrect.
Reporter | ||
Comment 2•4 years ago
|
||
(In reply to Vernon Van Steenkist from comment #1)
- If Firefox can connect to the local domain,
network.trr.mode 3
is being ignored and the test has failed.
Local domains are intentionally excluded from TRR, so you can connect to your router, raspberrypi, etc.
It's public domains that we are trying to shield from the local resolver.
Comment 3•4 years ago
|
||
Local domains are intentionally excluded from TRR, so you can connect to your router, raspberrypi, etc.
It's public domains that we are trying to shield from the local resolver.
According to your own documentation (3 - Only. Only use TRR, never use the native resolver.), only domains in network.trr.builtin-excluded-domains
are supposed to be excluded from DoH with network.trr.mode 3
. If you disagree, please explain the difference between network.trr.mode 3
and network.trr.mode 2
.
Again network.trr.mode 3
functioned correctly in Firefox Version 68.11.0esr where only domains in network.trr.builtin-excluded-domains
were excluded from DoH.
With Firefox version 79, there is no longer any difference between network.trr.mode 3
and network.trr.mode 2
and the local DNS is used in network.trr.mode 3
even when not included in network.trr.builtin-excluded-domains
. Please correcr this ASAP.
Reporter | ||
Comment 4•4 years ago
|
||
(In reply to Vernon Van Steenkist from comment #3)
Local domains are intentionally excluded from TRR, so you can connect to your router, raspberrypi, etc.
Againnetwork.trr.mode 3
functioned correctly in Firefox Version 68.11.0esr where only domains innetwork.trr.builtin-excluded-domains
were excluded from DoH.
That's tracked in bug 1652427 - not related to this bug.
Comment 5•4 years ago
|
||
Thanks for your relpy and clarification.
Updated•2 years ago
|
Description
•