1820324 - Make the Unable to connect dialog more verbose (show the IP address for a remote server)

Status: UNCONFIRMED

(Core :: Networking, defect, P2)

Description

[Artem S. Tashkinov]

Steps to reproduce:

Let me be brutally honest: https://mozilla.cloudflare-dns.com/dns-query sucks.

I'm talking about DoH enabled using the default DNS provider.

in 99 out of 100 cases it resolves www.phoronix.com into the IP address which is not reachable from my current location, thus I get the infamous error:

Unable to connect.

The issue is I have no ways of knowing which IP address Firefox cannot connect to, so I cannot ping or traceroute it. And I definitely don't want to start debugging Firefox or enabling developer tools. As soon as I disable DoH via network.trr.mode -> 0 it all starts working so my system-wide/OS resolver gets the IP address correctly.

It would be extremely helpful, I guess for millions of your users, if Firefox simply showed the resolved IP address for the remote host it's trying to connect to.

Thank you very much.

Actual results:

My system resolver:

Non-authoritative answer:
Name: www.phoronix.com
Address: 104.21.42.68
Name: www.phoronix.com
Address: 172.67.158.124

Firefox resolver:
188.114.96.3

$ ping 188.114.96.3
PING 188.114.96.3 (188.114.96.3) 56(84) bytes of data.
^C
--- 188.114.96.3 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5098ms

Expected results:

The connection has timed out

An error occurred during a connection to www.phoronix.com (IP: 188.114.96.3).

• The site could be temporarily unavailable or too busy. Try again in a few moments.
• If you are unable to load any pages, check your computer’s network connection.
• If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the web.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Artem S. Tashkinov]

It would also be nice to know:

• Which resolver has been used and
• Whether Firefox could retrieve the remote host IP address in the first place

Too often a failure to open a website is down to the resolver and Firefox gives you zero information.

Comment 3

[Valentin Gosu [:valentin] (he/him)]

Thank you for your report. I agree that this is not optimal behaviour.
What TRR mode are you using? 2 or 3?
In mode2 we have a fallback mechanism which would let the connection manager use an IP not resolved by TRR if all of the ones resolved with TRR had failed.

Could you check if cloudflare gives you better IP addresses if you flip the network.trr.disable-ECS pref to false?

Comment 4

[Artem S. Tashkinov]

TRR mode 2 here - it does not fail, it returns inaccessible IPs altogether.

No idea what's wrong with cloudflare.

Comment 5

[Valentin Gosu [:valentin] (he/him)]

Could you capture some HTTP logs for us while reproducing this bug?
https://firefox-source-docs.mozilla.org/networking/http/logging.html
I feel like this should work, and it's not clear to me why it doesn't. Thanks.

Comment 6

[Artem S. Tashkinov]

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

Could you capture some HTTP logs for us while reproducing this bug?
https://firefox-source-docs.mozilla.org/networking/http/logging.html
I feel like this should work, and it's not clear to me why it doesn't. Thanks.

What are we chasing here exactly?

For this particular website Firefox' own DNS resolver, when TRR is set to 2, resolves to the inaccessible IP addresses.

The system resolver returns the working IP addresses.

Those two should not be intermingled because the DoH option in Firefox exists for a reason - trying to use the system resolver IP in addition to the IP addresses returned by DoH poses a security threat/leak.

This bug report is not about DNS/IP resolution issues, it's about being a tad more verbose to let the user understand what's going on.

To be honest Firefox could even be more verbose:

• We have tried to resolve example.org via (the DOH server|system configured DNS resolver with this IP address)
• We have received these IP addresses: 1.1.1.1, 2.2.2.2.
• Firefox couldn't connect to example.org using either of these IP addresses.

In case the resolver doesn't work, no matter which it is, Firefox could be quite brief:

Firefox has failed to get the IP addresses for example.org because the configured DNS resolver 1) couldn't be reached 2) didn't return anything

I know it all becomes a little bit technical but this information could be hidden behind e.g. the "Why?'" button or something, not to frighten the inexperienced users.

Comment 7

[Valentin Gosu [:valentin] (he/him)]

We are currently working on some UI improvements to DoH error pages in bug 1596839.
I agree that it would probably make a lot of sense to also display the IP connecting to a page failed.

The reason I'm asking you for some logs is this. In TRR mode 2, we normally fallback to native DNS when there's an issue. If we can't connect to an IP returned by TRR, we fallback to native DNS. It seems that in your case that mechanism isn't working properly, and I'm curious why that's the case.
Could you capture some logs for us? We can move the investigation into a new bug if you think that's OK.

Comment 8

[Artem S. Tashkinov]

That sounds reasonable but opens a security risk/leads to a possible unintended DNS leak. Is this really intentional? I don't think people who enable DoH want to use the system resolver (the fallback mechanism) at all.

If that's intentional, I'll check network logs.

Comment 9

[Valentin Gosu [:valentin] (he/him)]

Yes, network.trr.mode = 2 is the default, and it means fallback to native in case of failure.
mode = 3 is strict mode, and it doesn't normally fallback to native DNS.

Regular users just care about things working, which is why your use case should actually work.
It's best to test with a new profile, to avoid having private data (like cookies) in the logs. If you're still worried please email them to [e-mail]

Thanks!

Comment 10

[Artem S. Tashkinov]

I've emailed you the log file, probably it's in your SPAM folder.

Comment 11

[Artem S. Tashkinov]

version 111 is affected as well.