DNS being proxied regardless of settings
Categories
(Core :: Networking: DNS, defect)
Tracking
()
People
(Reporter: bugzilla_shad0ws, Unassigned)
Details
Attachments
(1 file)
193.80 KB,
image/png
|
Details |
Steps to reproduce:
- set up a private DNS resolver (sinkhole) to resolve some DNS queries to 0.0.0.0
- set up Firefox to use that resolver either via system DNS or via DNS-over-HTTPS
- enable SOCKS5 proxy in Firefox
- disable "Proxy DNS when using SOCKS v5" in Firefox
Actual results:
The website blocked via DNS loads and works fine
As you can see on the screenshot attached I used paypal.com as an example and it resolves to 0.0.0.0 on about:networking but still loads fine (second tab)
I can also reproduce this when turning DoH off and using system DNS
Expected results:
The website blocked via DNS should not open
Reporter | ||
Comment 1•2 months ago
|
||
Also: for some reason I can not reproduce it with a different SOCKS5 proxy so this is somehow depended on a proxy, but still looks like a Firefox bug
Comment 2•2 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking: DNS' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Are you be able to capture some HTTP logs using these instructions and send them to necko@mozilla.com?
Thanks!
Reporter | ||
Comment 4•2 months ago
|
||
sent the logs (both with system DNS and DNS over HTTPS) to above email
I used a clean install of Firefox v. 132.0.2 packaged as flatpak on Debian to reproduce the bug and capture the logs
I can also reproduce it on Firefox ESR v. 128.4.0 packaged by Debian if needed
Comment 5•2 months ago
|
||
(In reply to bugzilla_shad0ws from comment #4)
sent the logs (both with system DNS and DNS over HTTPS) to above email
I used a clean install of Firefox v. 132.0.2 packaged as flatpak on Debian to reproduce the bug and capture the logs
I can also reproduce it on Firefox ESR v. 128.4.0 packaged by Debian if needed
Thanks for the log.
From the log, I can see that the socket to paypal.com did try to connect with address 0.0.0.0.
2024-11-30 07:52:33.712189 UTC - [Parent 2: Socket Thread]: E/nsSocketTransport nsSocketTransport::Init [this=7ff1dd36c100 host=paypal.com:443 origin=paypal.com:443 proxy=127.0.0.1:1080]
2024-11-30 07:52:33.713970 UTC - [Parent 2: Socket Thread]: E/nsSocketTransport nsSocketTransport::SendStatus [this=7ff1dd36c100 status=4b0007]
2024-11-30 07:52:33.713982 UTC - [Parent 2: Socket Thread]: D/nsSocketTransport trying address: 0.0.0.0
Note that the log also shows that the page seems to be loaded as www.paypal.com
, so maybe you should also block www.paypal.com
not just paypal.com
?
Could you also check if www.paypal.com
also resolves to 0.0.0.0?
Reporter | ||
Comment 6•2 months ago
|
||
(In reply to Kershaw Chang [:kershaw] from comment #5)
Note that the log also shows that the page seems to be loaded as
www.paypal.com
, so maybe you should also blockwww.paypal.com
not justpaypal.com
?Could you also check if
www.paypal.com
also resolves to 0.0.0.0?
During my initial tests I assumed it may have something to do with HSTS and blocked www.paypal.com
too - it made no difference.
It was actually still blocked at DNS-over-HTTS resolver, this line is in the logs:
2024-11-30 07:55:44.610481 UTC - [Parent 2: TRR Background]: D/nsHostResolver CompleteLookup: www.paypal.com has 0.0.0.0
I double-checked it now: blocking www.paypal.com
makes no difference
I can also see in Developer Tools, Network tab that the first request when opening the website is paypal.com
and it is successful (redirect to www.paypal.com
which is the second request)
GET https://paypal.com/
Status 301
Version HTTP/2
Transferred 18.37 kB (84.15 kB size)
Request Priority Highest
DNS Resolution System
Response Headers
HTTP/2 301
date: Sat, 30 Nov 2024 07:48:22 GMT
location: https://www.paypal.com/
server: ECAcc (dce/26DE)
content-length: 0
X-Firefox-Spdy: h2
Still, I can provide logs with www.paypal.com
blocked via system DNS too, if it helps
Comment 7•2 months ago
|
||
I've reviewed the log again, and it shows that the 301 redirect response is from the HTTP cache. Additionally, the socket created for www.paypal.com is also using the address 0.0.0.0:
2024-11-30 07:55:44.610904 UTC - [Parent 2: Socket Thread]: D/nsSocketTransport creating nsSocketTransport @7ff1dd1edb00
2024-11-30 07:55:44.610915 UTC - [Parent 2: Socket Thread]: E/nsSocketTransport nsSocketTransport::Init [this=7ff1dd1edb00 host=www.paypal.com:443 origin=www.paypal.com:443 proxy=127.0.0.1:1080]
2024-11-30 07:55:44.612249 UTC - [Parent 2: Socket Thread]: E/nsSocketTransport nsSocketTransport::SendStatus [this=7ff1dd1edb00 status=4b0007]
2024-11-30 07:55:44.612259 UTC - [Parent 2: Socket Thread]: D/nsSocketTransport trying address: 0.0.0.0
It's still unclear why the proxy is attempting to resolve the hostname and connect. Could you try capturing the log again? This time, please add SOCKS:5
to the MOZ_LOG
environment variable.
Thanks!"
Reporter | ||
Comment 8•2 months ago
|
||
(In reply to Kershaw Chang [:kershaw] from comment #7)
It's still unclear why the proxy is attempting to resolve the hostname and connect. Could you try capturing the log again? This time, please add
SOCKS:5
to theMOZ_LOG
environment variable.
Done, thank you!
Updated•2 months ago
|
Comment 9•2 months ago
|
||
I've looked at the latest log, and it shows that Firefox resolved www.paypal.com
to 0.0.0.0
and provided this address to the SOCKS proxy. I can also confirm that during the SOCKS connection setup, Firefox did not perform any DNS lookup for www.paypal.com
, so I believe the DNS lookup was done by the SOCKS proxy itself. Since you can't reproduce this issue with a different SOCKS proxy, I think this is not a Firefox bug.
Feel free to reopen if you disagree. Thanks.
Reporter | ||
Comment 10•2 months ago
|
||
(In reply to Kershaw Chang [:kershaw] from comment #9)
Thanks a lot for looking into the report, I was not aware SOCKS proxy could do that
Description
•