Closed Bug 1593873 Opened 7 months ago Closed 7 months ago

Firefox ignores trr = 3 when resolving detectportal.firefox.com and incoming.telemetry.mozilla.org

Categories

(Core :: Networking: DNS, defect)

72 Branch
defect
Not set
normal

Tracking

()

RESOLVED INVALID
Tracking Status
firefox72 --- affected

People

(Reporter: etrapani, Unassigned)

References

Details

(Keywords: nightly-community)

If network.trr.mode = 3 (only use TRR) Firefox still resolves the following address with the native resolver.

detectportal.firefox.com

While quitting, it also resolves incoming.telemetry.mozilla.org with the native resolver.

Summary: Firefox ignores trr = 3 when resolving detectportal.firefox.com → Firefox ignores trr = 3 when resolving detectportal.firefox.com and incoming.telemetry.mozilla.org
Component: General → Networking: DNS
Product: Firefox → Core

IIRC it's on purpose. Is that right, Valentin?

Flags: needinfo?(valentin.gosu)

Yes, this is on purpose. Captive portal detection is useless if you don't use the native resolver.

The when quitting bit is not expected, but we have a different bug for that.

Status: NEW → RESOLVED
Closed: 7 months ago
Flags: needinfo?(valentin.gosu)
Resolution: --- → INVALID

(In reply to Valentin Gosu [:valentin] (he/him) from comment #3)

Yes, this is on purpose. Captive portal detection is useless if you don't use the native resolver.

I get it, but the idea of trr = 3 is not to use the local resolver ever. Maybe there should be no detection with that setting then.

The when quitting bit is not expected, but we have a different bug for that.

I cannot find it, could you please provide the number so that I can add me to the CC list?

Flags: needinfo?(valentin.gosu)

(In reply to Eduardo Trápani from comment #4)

The when quitting bit is not expected, but we have a different bug for that.

I cannot find it, could you please provide the number so that I can add me to the CC list?

Ooops, missed this ni.
I was wrong that we had a different bug for that. That is actually expected behaviour, since it happens in a different process:
https://searchfox.org/mozilla-central/rev/803a42f24c8714631ed81cb824ea1c1a803cb7b8/toolkit/components/telemetry/fog/src/lib.rs#162

Flags: needinfo?(valentin.gosu)

Somebody setting network.trr.mode =3 is clearly asking Firefox to be DNS-silent (standard resolution). The fact that instead the user gets a beacon at the beginning and end of the session is rather unexpected.

From the wiki https://wiki.mozilla.org/Trusted_Recursive_Resolver, the native resolver is NEVER used.

3 - Only. Only use TRR. Never use the native (This mode also requires the bootstrapAddress pref to be set)

See Also: → 1610365

(In reply to Eduardo Trápani from comment #6)

Somebody setting network.trr.mode =3 is clearly asking Firefox to be DNS-silent (standard resolution). The fact that instead the user gets a beacon at the beginning and end of the session is rather unexpected.

There are some important notes here:

  1. We exclude the captive portal domain because by definition the captive portal works with local DNS. Doing the checks using TRR doesn't make much sense.
  2. There are other ways we intentionally bypass mode3: if you've got OS level parental controls on, for the domains in network.trr.excluded-domains for any subdomains of the DNS suffix list (such as .lan, .local, etc)

In any case, I filed bug 1610365 to reconsider the telemetry question.

You can network.captive-portal-service.enabled to false to get rid of that in about:networking#dns...

You need to log in before you can comment on or make changes to this bug.