Beauty@LHC Alpha offline since 2017-03-06 18:48:30
Najmanovich Research Group Alpha offline since 2017-03-06 18:47:35
RALPH@Home Alpha offline since 2017-03-06 18:46:13
Rosetta@Home Production offline since 2017-03-06 18:45:29

Are these projects sharing the same network or DNS provider? They're offline since times are really close.

Update: Seems to be a DNS update problem with Rosetta@Home at least -- their DNS SOA shows an update today and it looks like BAKERLAB.ORG NS servers moved and we have to wait for the existing TTL to expire.

I noticed that, too, and was wondering some of the same things. Thanks for the DNS information you provided.

For what little it's worth, I'm mostly running rosetta@home these days, to the turn of over 3 million "Word done" 'points', but the deadlines are still annoying and in my opinion create lots of inefficiency for reasons I have NEVER been able to figure out. If you need deadlines, then you better buy your own supercomputer, eh?

Looks like the TLD for .org hasn't updated their glue records to point the bakerlabs.org domain name servers to bakerlab's internal servers. This is an avoidable problem if bakerlabs hosted their SOA and NS server records elsewhere, e.g. with their domain registrar.

C:>dig bakerlab.org ns @a.root-servers.net

; <<>> DiG 9.11.0-P3 <<>> bakerlab.org ns @a.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40558
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 13
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;bakerlab.org. IN NS

;; AUTHORITY SECTION:
org. 172800 IN NS a0.org.afilias-nst.info.
org. 172800 IN NS a2.org.afilias-nst.info.
org. 172800 IN NS b0.org.afilias-nst.org.
org. 172800 IN NS b2.org.afilias-nst.org.
org. 172800 IN NS c0.org.afilias-nst.info.
org. 172800 IN NS d0.org.afilias-nst.org.

;; ADDITIONAL SECTION:
a0.org.afilias-nst.info. 172800 IN A 199.19.56.1
a2.org.afilias-nst.info. 172800 IN A 199.249.112.1
b0.org.afilias-nst.org. 172800 IN A 199.19.54.1
b2.org.afilias-nst.org. 172800 IN A 199.249.120.1
c0.org.afilias-nst.info. 172800 IN A 199.19.53.1
d0.org.afilias-nst.org. 172800 IN A 199.19.57.1
a0.org.afilias-nst.info. 172800 IN AAAA 2001:500:e::1
a2.org.afilias-nst.info. 172800 IN AAAA 2001:500:40::1
b0.org.afilias-nst.org. 172800 IN AAAA 2001:500:c::1
b2.org.afilias-nst.org. 172800 IN AAAA 2001:500:48::1
c0.org.afilias-nst.info. 172800 IN AAAA 2001:500:b::1
d0.org.afilias-nst.org. 172800 IN AAAA 2001:500:f::1

;; Query time: 13 msec
;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)
;; WHEN: Mon Mar 06 23:38:29 Eastern Standard Time 2017
;; MSG SIZE rcvd: 443


C:>

----

But then when the afilias-nst servers are queried they don't show any NS records:

C:>dig bakerlab.org ns @a0.org.afilias-nst.info

; <<>> DiG 9.11.0-P3 <<>> bakerlab.org ns @a0.org.afilias-nst.info
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61853
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bakerlab.org. IN NS

;; AUTHORITY SECTION:
org. 900 IN SOA a0.org.afilias-nst.info. noc.afilias-nst.info. 2012394420 1800 900 604800 86400

;; Query time: 47 msec
;; SERVER: 2001:500:e::1#53(2001:500:e::1)
;; WHEN: Mon Mar 06 23:43:38 Eastern Standard Time 2017
;; MSG SIZE rcvd: 104


C:>

I'm not technical so I don't know what this means. Should it be solvable in relatively short time? Rosetta still down.

Basically they are trying to run their DNS from within their own domain. If you go that route (instead of using an external DNS hosting service) they need to tell the TLD (Top Level Domain) for their domain (in this case the .org domain admins) to specify a "glue record" which includes a hard IP address of the name server to avoid the chicken and egg problem of referring to their own domain to provide DNS responses/

In short: if you are looking for bakerlab.org and it's name server is ns1.bakerlab.org then you have no way to know where bakerlab.org even is without the .org DNS level forcing the issue with a hard IP address because you can't lookup ns1.bakerlab.org if you don't know where bakerlab.org is in the first place.

It's all explained here: https://help.1and1.com/domains-c36931/manage-domains-c79822/dns-c37586/explanation-of-a-glue-record-a595844.html

Thanks for your answer. Meanwhile, still no Rosetta...

Not much of an explanation if there is no solution there. Been several days now, and there is still no resolution.

My technical understanding is limited, but if they have messed up their DNS settings, is there some way to bypass it. I remember I used to tweak the hosts file in the old days when I needed to force an IP address. Something like that still possible with Windows 10? {Pause for research...] Yes, it's still here. So is it perhaps possible to temporarily fix rosetta@home by changing my hosts file for a few days?

The solution is trivial: The Rosetta sysadmin(s) need to contact the TLD for .org (afilias-nst.org) and have them add glue records (or do it via their registrar if they provide that service).

I agree, this is an amateur mistake and should have been fixed within the first day. Or, as I suggested, use an external DNS service which would also help guard against DNS attacks instead of trying to homebrew it. This is why operational competence matters -- architecting systems to be fault-tolerant, resistant to attack, and resilient matters when you consider the time and effort wasted on cleaning it all up later.

I contacted the University of Washington admin listed in the whois database and got this response:

----

We (bakerlab.org) had a domain verification lapse, and our registrar (dotster.com) and ICANN turned off DNS for bakerlab.org. We started going through the steps to getting it verified again Monday afternoon. What should have been a 10 minute procedure is now stretching into 4 days. I promise you that we're doing everything we can to get dotster and ICANN to resolve this.

The registrations for these domains are paid up through 2020. This is the result of the implementation of a fairly new and separate security measure. All our name servers are working, and if you point your machine's nameserver to one of ours, you could probably continue with you boinc projects. However I don't recommend that. I hope this problem will be solved soon, but it's out of our hands and I've hoped for a quick solution for for 3 days now.

I'm sorry for your inconvenience, and I really appreciate the contributions you and the many thousands of others have made to Rosetta@home

Sincerely,
Darwin

UPDATE from UW admin:

The DNS issue has beeen resolved, it's just a matter of propagation time and bad lookups to timeout and clear caches.