Closed Bug 1649370 Opened 4 years ago Closed 4 years ago

Server Not Found (but found by Chromium)

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Version:
77 Branch
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: graham, Unassigned)

Details

Attachments

(1 file)

FF-CIElog.txt-main.20667.moz_log log of trying to connect to https://www.cie.auckland.ac.nz
547.27 KB, application/octet-stream
Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

paste into address bar:
https://www.cie.auckland.ac.nz/newsroom/university-community-voices-the-need-for-a-revolution-for-new-zealands-natural-capital/

Actual results:

! Server not Found
Hmm. We’re having trouble finding that site.

We can’t connect to the server at cie.auckland.ac.nz.

Expected results:

When pasting the same URL into Chromium (Version 81.0.4044.138 (Official Build) Built on Ubuntu , running on LinuxMint 18.3 (64-bit) I get the page I expect.

Just checked with Firefox 78.0.1 (64-bit), same result.

Hi,

I was not able to reproduce this issue on Ubuntu 18.
Could you please try on our latest nightly build? You can download it from here: http://nightly.mozilla.org/. Also could you try with a NEW profile and in SAFE MODE (https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode) in case any configuration or addon is affecting.

Thanks.

Flags: needinfo?(graham)

First: Chromium continues to display https://www.cie.auckland.ac.nz/ fine.

Safe mode: exactly the same symptom, ie 'Server not found' and 'Hmm. We’re having trouble finding that site. We can’t connect to the server at www.cie.auckland.ac.nz.'

Flags: needinfo?(graham)

First: Chromium continues to display https://www.cie.auckland.ac.nz/ fine.

  • Safe mode: exactly the same symptom, ie 'Server not found' and 'Hmm. We’re having trouble finding that site. We can’t connect to the server at www.cie.auckland.ac.nz.'
  • blank profile: exactly the same symptom.
  • Nightly: exactly the same symptom.

bonus answer: $ ping www.cie.auckland.ac.nz
PING produ-loadb-1e48b9mbttc1q-014f04018fa852fb.elb.ap-southeast-2.amazonaws.com (13.55.10.250) 56(84) bytes of data.
{no response}

Anything else I can usefully do to help diagnose?

This is not the only site that has had such problems recently, but I think I read that there was a general problem with different browsers' interpretation of encryption protocol standards and this was being worked on in '78.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Address Bar

Are you using a DNS or proxy with Firefox? Please try creating a new profile and reproducing the problem there: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles

Flags: needinfo?(graham)

No I am not using an http proxy (with either browser).

For DNS, I have no proxy on my machines. My ISP is one of two defined DNS servers, the other is google (8.8.8.8). These are set in my router and delivered via DHCP to my laptop.

I created a brand new, empty profile using about:profiles and used "Launch profile in new browser". The result was identical to my usual profile.

Hope this helps,

Flags: needinfo?(graham)

Is your Firefox built/packaged by Ubuntu or is it an official build? You say you tested Chromium on LinuxMint but your comment 0 also indicates that you posted it on Ubuntu; are you running Firefox and Chromium on the same distro? Do you have a firewall or any other software that might be blocking Firefox's access to your network?

Definitely Linux Mint 18.3. I presume Firefox provided the upstream distribution instead in the initial trouble report.
I am running both browsers on the same system- currently Firefox 80 Nightly is my daily driver, i go to Chromium when I have to because of issues like this, and for jobs where I want two different browsers.
I have ufw on the machine but on/off makes no difference. The router has a firewall of sorts, but that's common to both browsers.

Because we hit an error page, it's clear the urlbar tries to send the url down to network, and the url doesn't contain any strange char that we may mis-interpret. Thus I think this needs network debugging.

Component: Address Bar → Networking
Product: Firefox → Core

something like a pcap? Here's all there is- three copies of this interaction, then nothing more before the error message.

No. Time Source Destination Protocol Length Info
31 4.166530907 192.168.1.66 210.55.111.1 DNS 82 Standard query 0x9bae A www.cie.auckland.ac.nz

Frame 31: 82 bytes on wire (656 bits), 82 bytes captured (656 bits) on interface 0
Ethernet II, Src: IntelCor_07:e9:b4 (3c:a9:f4:07:e9:b4), Dst: HuaweiTe_2c:c1:76 (3c:df:bd:2c:c1:76)
Internet Protocol Version 4, Src: 192.168.1.66, Dst: 210.55.111.1
User Datagram Protocol, Src Port: 50067, Dst Port: 53
Domain Name System (query)
Transaction ID: 0x9bae
Flags: 0x0100 Standard query
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
[Response In: 32]

No. Time Source Destination Protocol Length Info
32 4.172762638 210.55.111.1 192.168.1.66 DNS 348 Standard query response 0x9bae A www.cie.auckland.ac.nz CNAME www.cie.auckland.ac.nz.c14057.campuspress.com CNAME cloudflare-resolve-to.c14057.campuspress.com CNAME ap-southeast-2.lb.campuspress.com CNAME sydney.ap-southeast-2.lb.campuspress.com CNAME produ-loadb-1e48b9mbttc1q-014f04018fa852fb.elb.ap-southeast-2.amazonaws.com A 52.62.79.83 A 13.55.10.250

Frame 32: 348 bytes on wire (2784 bits), 348 bytes captured (2784 bits) on interface 0
Ethernet II, Src: HuaweiTe_2c:c1:76 (3c:df:bd:2c:c1:76), Dst: IntelCor_07:e9:b4 (3c:a9:f4:07:e9:b4)
Internet Protocol Version 4, Src: 210.55.111.1, Dst: 192.168.1.66
User Datagram Protocol, Src Port: 53, Dst Port: 50067
Domain Name System (response)
Transaction ID: 0x9bae
Flags: 0x8180 Standard query response, No error
Questions: 1
Answer RRs: 7
Authority RRs: 0
Additional RRs: 0
Queries
Answers
www.cie.auckland.ac.nz: type CNAME, class IN, cname www.cie.auckland.ac.nz.c14057.campuspress.com
www.cie.auckland.ac.nz.c14057.campuspress.com: type CNAME, class IN, cname cloudflare-resolve-to.c14057.campuspress.com
cloudflare-resolve-to.c14057.campuspress.com: type CNAME, class IN, cname ap-southeast-2.lb.campuspress.com
ap-southeast-2.lb.campuspress.com: type CNAME, class IN, cname sydney.ap-southeast-2.lb.campuspress.com
sydney.ap-southeast-2.lb.campuspress.com: type CNAME, class IN, cname produ-loadb-1e48b9mbttc1q-014f04018fa852fb.elb.ap-southeast-2.amazonaws.com
produ-loadb-1e48b9mbttc1q-014f04018fa852fb.elb.ap-southeast-2.amazonaws.com: type A, class IN, addr 52.62.79.83
produ-loadb-1e48b9mbttc1q-014f04018fa852fb.elb.ap-southeast-2.amazonaws.com: type A, class IN, addr 13.55.10.250
[Request In: 31]
[Time: 0.006231731 seconds]

Can we get a log? I also cannot repro. DNS all looks good, getting responses off both IPs using (curl with --resolve option) and in FF 78.0.2 on Linux (Fedora 32).

Flags: needinfo?(graham)

doesn't the pcap output above count as a log of the Firefox interaction? I don't know another way.
I don't use Fedora, so no use asking me for that. Further, at the request of a previous developer I 'upgraded' to Nightly so FF 80. I do SO wish I could get off this nightly, but I have not found a way.
I don't often use curl so if you would like me to give you a curl output, please give me a full command to get what you want to see.

Please see the link, there's a specific verbose Firefox network log that I'm requesting. Start the log, try to visit the site, stop the log, and attach it to this bug, if you don't mind.

Flags: needinfo?(graham)

User interface response was:
Hmm. We’re having trouble finding that site.
We can’t connect to the server at www.cie.auckland.ac.nz.

Thanks! Um.. Junior, do you have a few minutes to look at this log?

Flags: needinfo?(juhsu)

We delegate DNS resolution to OS, which matches comment 4.
Therefore, I'd like to close this bug.

Would you like to try DNS over HTTPS?
https://support.mozilla.org/en-US/kb/firefox-dns-over-https#w_manually-enabling-and-disabling-dns-over-https

2020-07-22 22:06:33.574934 UTC - [Parent 20667: Socket Thread]: D/nsHostResolver Resolving host [www.cie.auckland.ac.nz]<^partitionKey=%28https%2Cauckland.ac.nz%29> type 0. [this=0x7fdb329296d0]
2020-07-22 22:06:33.574949 UTC - [Parent 20667: Socket Thread]: D/nsHostResolver   No usable record in cache for host [www.cie.auckland.ac.nz] type 0.
2020-07-22 22:06:33.574956 UTC - [Parent 20667: Socket Thread]: D/nsHostResolver NameLookup host:www.cie.auckland.ac.nz af:0
2020-07-22 22:06:33.574963 UTC - [Parent 20667: Socket Thread]: D/nsHostResolver NameLookup: www.cie.auckland.ac.nz effectiveTRRmode: 1 flags: 0
2020-07-22 22:06:33.575044 UTC - [Parent 20667: Main Thread]: D/nsHttp sending progress and status notification [this=0x7fdafd495000 status=804b0003 progress=0/0]
  804b0003 = STATUS_RESOLVING
2020-07-22 22:06:33.575601 UTC - [Parent 20667: Socket Thread]: D/nsHostResolver   DNS thread counters: total=3 any-live=0 idle=3 pending=1
2020-07-22 22:06:33.575615 UTC - [Parent 20667: Socket Thread]: D/nsHostResolver   DNS lookup for host [www.cie.auckland.ac.nz] blocking pending 'getaddrinfo' or trr query: callback [0x7fdb0972a640]
2020-07-22 22:06:33.575629 UTC - [Parent 20667: DNS Resolver #37]: E/nsHostResolver DNS lookup thread - Calling getaddrinfo for host [www.cie.auckland.ac.nz].
2020-07-22 22:06:33.590743 UTC - [Parent 20667: DNS Resolver #37]: D/nsHostResolver Calling 'res_ninit'.
2020-07-22 22:06:33.711851 UTC - [Parent 20667: DNS Resolver #37]: E/nsHostResolver DNS lookup thread - lookup completed for host [www.cie.auckland.ac.nz]: failure: unknown host.
2020-07-22 22:06:33.711913 UTC - [Parent 20667: DNS Resolver #37]: D/nsHostResolver nsHostResolver::CompleteLookup www.cie.auckland.ac.nz (nil) 804B001E trr=0 stillResolving=0
2020-07-22 22:06:33.711931 UTC - [Parent 20667: DNS Resolver #37]: D/nsHostResolver nsHostResolver record 0x7fdb1e057e90 new gencnt
2020-07-22 22:06:33.711958 UTC - [Parent 20667: DNS Resolver #37]: D/nsHostResolver Caching host [www.cie.auckland.ac.nz] negative record for 60 seconds.
2020-07-22 22:06:33.711970 UTC - [Parent 20667: DNS Resolver #37]: D/nsHostResolver CompleteLookup: www.cie.auckland.ac.nz has NO address
2020-07-22 22:06:33.711981 UTC - [Parent 20667: DNS Resolver #37]: D/nsHostResolver nsHostResolver record 0x7fdb1e057e90 calling back dns users
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(juhsu)
Resolution: --- → INVALID

DNS over HTTPS resolved it immediately.

If it's the OS' problem, odd that Chromium doesn't suffer from it and I can also confirm that Epiphany browser also works with no configuration.

I'm curious that this is so easily dismissed as 'not a problem' given Firefox appears to fail where other browsers succeed. Why not make DNS over https the default, or at least an automatic fallback after a conventional DNS failure?

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: