1920105 - Firefox DNS is not working.

Status: RESOLVED DUPLICATE of bug 1919173

(External Software Affecting Firefox :: Other, defect)

Description

[Matthew Venne]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36

Steps to reproduce:

Firefox is not recognizing DNS results. I am using MacOS Sequoia. EVery website says Server not found. I took a wireshark and I see the DNS requests going through (it's unencrypted and confirmed it was the domains I was attempting). Wireshark shows that responses were returned from the queries. However, Firefox does not recognize the DNS response and it says server not found for all domains.

I have toggled DNS prefetch and DNS prefetch for HTTPS. Still nothing.

Comment 1

[Matthew Venne]

Please note that I am unable to provide the user agent string the DNS lookup is not being recognized.

Comment 2

[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 3

[Kershaw Chang [:kershaw]]

Hi, Matthew,

Could you try to capture a http log with the steps below?

1. Start Firefox
2. Go to about:logging
3. Make sure logging presets is Networking and select logging to file
4. Start logging.
5. Visit a simple website, e.g, google.com or example.com
6. Stop logging and send the log file to [e-mail]

Thanks.

Comment 4

[Matthew Venne]

Thank you, sent.

Comment 5

[Matthew Venne]

Do you have any upates on this?

Comment 6

[Sunil Mayya]

Thank you for sharing the http logs.
From the logs, it looks like the DNS is resolved correctly but the channel is cancelled from the search suggestion controller.
``
1966 2024-09-20 16:05:50.502560 UTC - [Parent 1465: Main Thread]: D/nsHttp nsHttpChannel::Cancel [this=100b6d200 status=804b0002, reason=XMLHttpRequestMainThread::CloseRequest]
1967 2024-09-20 16:05:50.502660 UTC - [Parent 1465: Main Thread]: D/nsHttp 100b6d200 called from script: resource://gre/modules/SearchSuggestionController.sys.mjs:357:35
...
4469 2024-09-20 16:05:51.089705 UTC - [Parent 1465: Main Thread]: D/nsHttp nsHttpChannel::Cancel [this=1121acc00 status=804b0002, reason=XMLHttpRequestMainThread::CloseRequest]
4470 2024-09-20 16:05:51.089814 UTC - [Parent 1465: Main Thread]: D/nsHttp 1121acc00 called from script: resource://gre/modules/SearchSuggestionController.sys.mjs:357:35
....
5651 2024-09-20 16:05:51.163312 UTC - [Parent 1465: Main Thread]: D/nsHttp nsHttpChannel::Cancel [this=1121b3a00 status=804b0002, reason=XMLHttpRequestMainThread::CloseRequest]
5652 2024-09-20 16:05:51.163366 UTC - [Parent 1465: Main Thread]: D/nsHttp 1121b3a00 called from script: resource://gre/modules/SearchSuggestionController.sys.mjs:357:35
.....

Mark, do you have any clues on why the channels were cancelled from the controller. Do we need additional logs to investigate this further?

Comment 7

[Matthew Venne]

Let me know if you need anything from me.

I use Firefox as my main browser and the past few days have been annoying. So anything I can do to assist would be greatly appreciated.

FWIW. It won’t even recognize entries in hosts file like localhost, but if I browse 127.0.0.1 it works.

Comment 8

[Kershaw Chang [:kershaw]]

This has nothing to do with the search request. I assume it's cancelled because of the the text change in the address bar or something else.

The request we should look at is this one:

2024-09-20 16:05:54.334420 UTC - [Parent 1465: Main Thread]: E/nsHttp HttpBaseChannel::Init [this=1368d6a00]
2024-09-20 16:05:54.334429 UTC - [Parent 1465: Main Thread]: E/nsHttp uri=https://www.espn.com/
2024-09-20 16:05:54.334436 UTC - [Parent 1465: Main Thread]: E/nsHttp nsHttpChannel::Init [this=1368d6a00]
...
2024-09-20 16:06:07.854883 UTC - [Parent 1465: Main Thread]: D/nsHttp nsHttpChannel::Cancel [this=1368d6a00 status=804b0002, reason=CanonicalBrowsingContext::CanonicalDiscard]
2024-09-20 16:06:07.854967 UTC - [Parent 1465: Main Thread]: D/nsHttp 1368d6a00 called from script: chrome://browser/content/tabbrowser/tabbrowser.js:4549:15
2024-09-20 16:06:07.854975 UTC - [Parent 1465: Main Thread]: D/nsHttp nsHttpChannel::CancelInternal [this=1368d6a00]

As you can see, this request was cancelled after 13s, so the question is why this request took so long to complete.
Since the reporter suggested this is a DNS issue, we should also look at if the host www.espn.com was resolved successfully.
Looking at the log, we can see this GetAddrInfo call:

2024-09-20 16:05:54.346555 UTC - [Parent 1465: DNS Resolver #46]: E/nsHostResolver DNS lookup thread - Calling getaddrinfo for host [www.espn.com].

However, this call seems to be blocked and never completed.

I think this bug may be share the same reason as bug 1912231.
Matthew, could you check if this is related to your firewall setting?

Comment 9

[Mark Banner (:standard8)]

If this is related to the firewall, there's a request in bug 1919173 comment 11 for reporting to Apple, and there's a support page here with more information https://support.mozilla.org/kb/firefox-blocked-macos-15-sequoia-firewall-what-you

Comment 10

[Matthew Venne]

Thanks will have to work with corporate IT to get that sorted out, as it's managed by Intune. I can see that Firefox is listed as blocking incoming connections - any idea why firefox requires incoming connections? Is this something new in 130 build?

Once I get that removed, I will report back if the bug is fixed.

Comment 11

[Matthew Venne]

Ok - I can confirm adding Firefox as an exception to blocked incoming connections in firewall settings resolves my issue.

Comment 12

[Haik Aftandilian [:haik]]

(In reply to Matthew Venne from comment #11)

Ok - I can confirm adding Firefox as an exception to blocked incoming connections in firewall settings resolves my issue.

Given the firewall changed resolved the problem, this appears to be a duplicate of bug 1919173.

Comment 13

[Matthew Venne]

I am re-opening this issue. It appears to have come back. Despite firefox still being allowed by my firewall. It seems to be related to Sequoia because one of my coworker's is experiencing the same issue but just with Safari. I will be opening a ticket with apple support and will report back any findings.