Closed Bug 1891423 Opened 1 year ago Closed 1 year ago

Hosts file no longer blocks some sites since native HTTPS resolver was enabled on Ubuntu

Categories

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

Firefox 125
defect

Tracking

()

RESOLVED DUPLICATE of bug 1893944
Tracking Status
firefox-esr115 --- unaffected
firefox125 --- disabled
firefox126 --- disabled
firefox127 --- affected

People

(Reporter: ke5trel, Assigned: kershaw)

References

(Blocks 1 open bug, Regression, )

Details

(Keywords: regression, Whiteboard: [necko-triaged])

Attachments

(1 file)

STR:

  1. Block www.youtube.com using /etc/hosts on Ubuntu 23.10.
  2. Set DoH to Off.
  3. Visit www.youtube.com.

Site loads instead of being blocked.

Other sites like www.facebook.com can still be blocked.

Using about:networking#dnslookuptool returns:

IPs
127.0.0.1

HTTP RRs
1 youtube-ui.l.google.com ()

Adding youtube-ui.l.google.com to the hosts file allows the block to work.

Changing network.dns.native_https_query = false stops returning HTTP RRs and avoids the issue.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4c5285764100fef7429262fb418cb665ea747427&tochange=8a936faee760859d530e2fbc7d8ac3d0294385b5

Regressed by Bug 1874464.

:valentin, since you are the author of the regressor, bug 1874464, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Flags: needinfo?(valentin.gosu)

It seems this is caused by this line.
We're using the CNAME returned in the HTTPS record for the new connection info, that means we end up using youtube-ui.l.google.com instead of www.youtube.com in the connection info.
HTTPSSVC: use new routed host (youtube-ui.l.google.com) and new npnToken (None)

Potential solutions:

  • wait for IP lookups to complete before using HTTPS record (but even if they do, and point to 127.0.0.1, we might have to make a decision whether to use it).
  • Not do HTTPS lookups for domains that have an entry in /etc/hosts
  • something else?

Kershaw, what do you think?

Flags: needinfo?(valentin.gosu) → needinfo?(kershaw)
  • Not do HTTPS lookups for domains that have an entry in /etc/hosts

I think this is the easiest approach to be implemented and is less likely to cause any regression.
I'll take this bug.

Assignee: nobody → kershaw
Severity: -- → S3
Flags: needinfo?(kershaw)
Priority: -- → P2
Whiteboard: [necko-triaged]

Do you have the necessary read permissions on a sandboxed system like Android?

Setting 126 to disabled by Bug 1893970

FYI, this one should be fixed by bug 1893944.

Status: NEW → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1893944
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: