I was trying to check the menu of my local food co-op’s café, but both websites give me a “Firefox can’t find the server at …” message in Firefox. Since they’re both .coop domains, I tried a couple others I could think of, including the registrar (http://nic.coop), all give the same result.
I’ve now tried
several browsers (Firefox, Firefox Nightly, Chromium, Gnome Web)
ping, which also can’t resolve them (“Name or service not known”)
OTOH, I have no problem accessing .coop domains with other devices on the network, and even this same machine running MacOS.
I don’t remember doing any network configuration except signing into my wifi network. I double checked that there is no system or Firefox proxy and no firewall turned on.
Can someone else try a .coop domain or two to see if you get the same issue?
On the other hand, I just booted into zesty and have gotten Server not found on on all three links, coop, café and registrar. And I am using the same Firefox profile on both systems. I wonder what’s going on?
I was googling to find what I should report the bug to, and then I accidentally clicked a .coop link … and it worked. So do all the other ones now. Very strange.
Ping can’t get any coop websites either. I’m going to log out and then back in.
Update: Ping not finding coop stuff. Chrome the same as Firefox, server not found. Changed my wireless DNS 2nd server to google’s 8.8.8.8 - no help.
More: Ping still gets ping: nic.coop: Name or service not known. FF and Chrome stymied even after hooking up ethernet cable.
Update: @anon42388993@elcste Logged out and back in. Ping works, elcste’s link to cafe works. This is not dependent upon ethernet either. What was the cause of all this? Any suspicions? I’m baffled…
Any DNS experts? I was getting a SERVFAIL but once I did a dig +trace coopcreamery.coop all is well. I think something is intermittent with the .coop TLD servers.
No problems accessing those .coop links here (16.04.2)
I only use Google's DNS servers: 8.8.8.8 and 8.8.4.4 (not as "additional DNS servers") - if this happens again, try them instead of the ones provided by your ISP / router.
When you edit your connection, ensure "addresses only" is chosen and then it will only use the DNS servers specified.
This is still a problem for me when logging into 17.04 beta2 (with all updates, etc.)
Firefox (version 50.1.0) seems to be a version or two behind 16.04 (version 52.0.2) .
Pinging coopcreamery.coop in the beta still gets service not known. 16.04 ping works every time.
It does not appear to be a DNS issue as far as I can tell having changed DNS several times, rebooted and no joy.
Network manager is (still) not working properly, showing two connections when I have an ethernet cable plugged into my laptop.
Got any ideas? (Edited for clarity, I’m rebooting at another machine ATM.)
Edit: I tried Bill’s suggestion above (dig +trace coopcreamery.coop) but it came back unresolved.
Network manager doesn’t work like other systray applets - only right click shows info and options. In 16.04 both right and left clicks work the same.
Strangely, the .coop link (coopcreamery.coop) began working in FF after about a half an hour while I was doing other stuff in the beta. I looked up and there was the Seward Creamery Cafe.
It’s been working sporadically for me when I’ve tried it all weekend, although more often not. I tried @lah’s7 suggestion of Google DNS, and it still doesn’t usually work for me.
I caught it only once and I think it was the Top-Level-Domain (TLD) level that screwed up. But I closed that terminal and haven’t been able to catch it again.
For anyone interested, I added +nodnssec to make the output of dig less confusing:
~$ dig +trace +nodnssec coopcreamery.coop
; <<>> DiG 9.10.3-P4-Ubuntu <<>> +trace +nodnssec coopcreamery.coop
;; global options: +cmd
. 156653 IN NS j.root-servers.net.
. 156653 IN NS m.root-servers.net.
. 156653 IN NS d.root-servers.net.
. 156653 IN NS g.root-servers.net.
. 156653 IN NS l.root-servers.net.
. 156653 IN NS k.root-servers.net.
. 156653 IN NS c.root-servers.net.
. 156653 IN NS f.root-servers.net.
. 156653 IN NS i.root-servers.net.
. 156653 IN NS a.root-servers.net.
. 156653 IN NS h.root-servers.net.
. 156653 IN NS b.root-servers.net.
. 156653 IN NS e.root-servers.net.
;; Received 811 bytes from 127.0.1.1#53(127.0.1.1) in 0 ms
*** Above FETCH ROOT SERVERS ***
coop. 172800 IN NS a.nic.coop.
coop. 172800 IN NS b.nic.coop.
coop. 172800 IN NS c.nic.coop.
coop. 172800 IN NS d.nic.coop.
;; Received 290 bytes from 192.203.230.10#53(e.root-servers.net) in 18 ms
*** Above GETTING TLDs FROM A ROOT SERVER ***
coopcreamery.coop. 3600 IN NS ns1.na.domains.coop.
coopcreamery.coop. 3600 IN NS ns2.na.domains.coop.
coopcreamery.coop. 3600 IN NS ns3.na.domains.coop.
coopcreamery.coop. 3600 IN NS ns4.na.domains.coop.
;; Received 129 bytes from 194.169.218.64#53(a.nic.coop) in 80 ms
*** Above GETTING AUTHORITATIVE SERVERS FROM A TLD ***
coopcreamery.coop. 28800 IN A 45.55.6.43
;; Received 62 bytes from 162.251.82.252#53(ns4.na.domains.coop) in 50 ms
*** Above GETTING ADDRESS FROM AUTHORITATIVE SERVER ***
~$
I placed *** 4 comments *** explaining each level of the trace so you can see where it’s screwing up. If it is at the TLDs, choice of DNS server will be a lucky draw of what it has cached.
This afternoon, I tried getting to coopcreamery in 16.04.2 via it's IP, 45.55.6.43. FF loaded it, or at least tried, as https://45.55.6.43/. I got the following connection not secure message.
Hi @mdooley, Not in this case. You’d be awhile trying to find a TLS/HTTPS site that includes their IP as a valid hostname in their certificate. Try some and see what I mean.
The clue that nothing is wrong is:
“The certificate is only valid for coopcreamery.coop”
where razvan posts per the bug report posted by django
What I have to do is go and shutdown systemd-resolved (sudo service systemd-resolved stop) and edit /etc/resolv.conf to point to 192.168.1.1 (my router) instead of 127.0.0.53.
This appears to temporarily fix my ability to successfully ping coopcreamery.coop which is nice to know.
