isLocalIPv4 should consider 0.0.0.0/8 a local address per RFC1122
Categories
(Core :: Networking: DNS, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox133 | --- | fixed |
People
(Reporter: maxime+mozilla, Assigned: maxime+mozilla, NeedInfo)
Details
(Whiteboard: [necko-triaged][necko-priority-next])
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0
Steps to reproduce:
In the Browser Console, execute the following JavaScript:
Services.io.hostnameIsLocalIPAddress(Services.io.newURI(`http://0.0.0.0`))
Actual results:
The Browser Console returns false
.
This impacts things like the DoH canary domain (use-application-dns.net
) where a 0.0.0.0
response is incorrectly considered positive. As an example, OPNsense's Unbound DNS Blocklist returns by default the local 0.0.0.0
IP for blocked domains 1, which FireFox would fail to consider a negative result.
Expected results:
The Browser Console should return true
for any IP within the 0.0.0.0/8
range as per RFC1122.
Currently only the 10/8
prefix (RFC 1918), 172.16/12
prefix (RFC 1918), 192.168/16
prefix (RFC 1918) and 169.254/16
prefix (Link Local) are considered local by isLocalIPv4
.
Assignee | ||
Comment 1•3 months ago
|
||
If this bug is considered valid, I would be happy to fix it as a first contribution.
Comment 2•3 months ago
|
||
Not that this specific address was likely to change use, but most of RFC 1122 has been updated and obsoleted over the past 35 years. For due diligence I'll note the IANA IPv4 Special-Purpose Address Registry confirms this block still has this meaning.
We will be blocking connections to 0.0.0.0 specifically in bug 1889130, but knowing it's local before we try could help in other cases. And this would be usefully correct for the unlikely case we encounter other 0.0.0.* addresses.
Comment 3•3 months ago
|
||
Valentin: is this a change your team would agree with?
Comment 4•3 months ago
|
||
Yes, I think this is something we should consider doing.
Assignee | ||
Comment 5•3 months ago
|
||
Updated•3 months ago
|
Comment 7•2 months ago
|
||
Backed out for causing xpcshell failures
- Backout link
- Push with failures
- Failure Log
- Failure line: TEST-UNEXPECTED-FAIL | netwerk/test/unit/test_dooh.js | xpcshell return code: 0
TEST-UNEXPECTED-FAIL | netwerk/test/unit/test_dooh.js | test_no_retry_without_doh - [test_no_retry_without_doh : 1056] Expecting only one instance of NS_NET_STATUS_RESOLVED_HOST - "undefined" == 1
TEST-UNEXPECTED-FAIL | netwerk/test/unit/test_trr.js | xpcshell return code: 0
TEST-UNEXPECTED-FAIL | netwerk/test/unit/test_trr.js | test_no_retry_without_doh - [test_no_retry_without_doh : 1056] Expecting only one instance of NS_NET_STATUS_RESOLVED_HOST - "undefined" == 1
Comment 9•2 months ago
|
||
bugherder |
Description
•