1850109 - Firefox uses system DNS resolution in some cases rather than that given in DNS over HTTPS

Status: UNCONFIRMED

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

Description

[Ved]

Attachment: Screenshot of DNS resolution

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

Visit some websites blocked by ISP. Visiting the network debugging tab shows the DNS resolution as system rather than DNS over HTTPS

Actual results:

Rather than loading, PR_CONNECT_RESET_ERROR error is shown.

Expected results:

Website should load.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 2

[Sunil Mayya]

Thank you for filing the report.

Can you please provide http logs when you get this error.
You can email the logs to [e-mail] if you are concerned about saving sensitive personal information in the tool.
Could you also please paste the DNS over HTTPS configuration that you are using?

Comment 3

[Ved]

I'm using a private DNS from https://dns.nextdns.io/

Comment 4

[Ved]

Attachment: HTTP logs

Comment 5

[Ved]

Attachment: Networking Logs

Comment 6

[Valentin Gosu [:valentin] (he/him) {{ PTO until Nov 5 }}]

Hi Ved,

It seems that your ISP is also blocking the connection to ign.com (probably just the IP)
Not sure why devtools is showing it used System DNS (possibly because the request failed, could be a bug).
Looking at the logs, it seems we fail to connect to the IP, so we add it to the blocklist, then proceed to retry at different times.
In this case I don't think there's an easy fix - I suggest trying a proxy or VPN to bypass the blocking.
I'll look into the devtools issue (you can also verify if DNS over HTTPS was used by going to about:networking#dns and checking the TRR column for ign.com).

2023-08-28 07:18:55.158000 UTC - [Parent 7900: Socket Thread]: D/nsSocketTransport nsSocketTransport::RecoverFromError [this=26612dddc00 state=4 cond=804b0014]
2023-08-28 07:18:55.158000 UTC - [Parent 7900: Socket Thread]: D/nsSocketTransport nsSocketTransport::RecoverFromError do not retry because mDoNotRetryToConnect is set [this=26612dddc00]
2023-08-28 07:18:55.158000 UTC - [Parent 7900: Socket Thread]: D/nsHostResolver Adding address to blocklist for host [www.ign.com], host record [266202a9860].used trr=1
2023-08-28 07:18:55.158000 UTC - [Parent 7900: Socket Thread]: D/nsHostResolver Successfully adding address [151.101.153.135] to blocklist for host [www.ign.com].

Comment 7

[Ved]

Yeah, the ISP blocks a few domains and that was one of the main reason, along with privacy, I started using DoH. What I find surprising is that, although torrent websites are also blocked by the ISP, Firefox is able to connect to it through DoH but ign.com is getting blocked.
And yeah, on checking the DNS tab on networking, it displays TRR as true for all ign.com and 1337x.com, yet only see an error with ign.com

Comment 8

[Kershaw Chang [:kershaw]]

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

Hi Ved,

It seems that your ISP is also blocking the connection to ign.com (probably just the IP)
Not sure why devtools is showing it used System DNS (possibly because the request failed, could be a bug).

I think devtools is using ResolvedByTRR to determine if DoH is used or not. However, ResolvedByTRR is set in nsHttpChannel::OnTransportStatus. However, nsHttpChannel::OnTransportStatus won't be called when the HTTP request is severed from cache or the HTTP request is failed.
I think that's the reason why devtools shows System DNS is used.

Comment 9

[Ved]

(In reply to Kershaw Chang [:kershaw] from comment #8)

I think that's the reason why devtools shows System DNS is used.
If it's just an issue with the display and DNS from DoH is being used, then why are only some of the websites showing an error when trying to connect?

Comment 10

[Hubert Boma Manilla (:bomsy)]

(In reply to Kershaw Chang [:kershaw] from comment #8)

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

Hi Ved,

It seems that your ISP is also blocking the connection to ign.com (probably just the IP)
Not sure why devtools is showing it used System DNS (possibly because the request failed, could be a bug).

I think devtools is using ResolvedByTRR to determine if DoH is used or not. However, ResolvedByTRR is set in nsHttpChannel::OnTransportStatus. However, nsHttpChannel::OnTransportStatus won't be called when the HTTP request is severed from cache or the HTTP request is failed.
I think that's the reason why devtools shows System DNS is used.

Hi Kershaw, is there a better API that could be used instead?

Comment 11

[Kershaw Chang [:kershaw]]

(In reply to Hubert Boma Manilla (:bomsy) from comment #10)

(In reply to Kershaw Chang [:kershaw] from comment #8)

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

Hi Ved,

It seems that your ISP is also blocking the connection to ign.com (probably just the IP)
Not sure why devtools is showing it used System DNS (possibly because the request failed, could be a bug).

I think devtools is using ResolvedByTRR to determine if DoH is used or not. However, ResolvedByTRR is set in nsHttpChannel::OnTransportStatus. However, nsHttpChannel::OnTransportStatus won't be called when the HTTP request is severed from cache or the HTTP request is failed.
I think that's the reason why devtools shows System DNS is used.

Hi Kershaw, is there a better API that could be used instead?

We can maybe reuse the logic here. That code returns the current DoH status. So, when the channel is coming from cache, we use the global DoH status instead.

What do you think?

Comment 12

[Valentin Gosu [:valentin] (he/him) {{ PTO until Nov 5 }}]

I think we should consider what DNS Resolution is used for. Since it is attached to a request, I understand it to mean how did we resolve the name we used to get this resource. So if it is an IP address, we didn't really use any DNS. If we served the resource from cache, we may have used native DNS or DoH, but we didn't actually connect to that IP since the resource was in the cache, right?
So I think we can fix this by looking at whether the channel is served from cache.
We could also do an even weirder thing, and use nsIDNSService.asyncResolve with the RESOLVE_OFFLINE flag in order to get the cached DNS entry and check if it used DoH or not.