Well, after looking at it again, there is one thing that I had not considered. The redirect might be valid, but my DNS provider is having trouble with the host in the URL. And yes, that seems to be a real possibility, particularly since you say you can reach both URLs. Whois.internic.net says boinc2.ssl.berkeley.edu.nyud.net resolves, but Earthlink's name servers don't know it exists.

It may be bad form to reply to your own posts, but a quick test just confirmed that the issue (for me anyway) is that Earthlink's DNS through DHCP is not resolving the redirected host. I hand entered name servers, including one that the whois report listed for the nyud.net domain. Voila! The download host for setiathome_5.27_windows_intelx86.exe resolved and the file downloaded. Too bad it failed the checksum validation, but a retry should get a clean copy.

---

LOL...

No problemo, on the self reply. I would have saved you that 'embarassment', but I went to bed! ;-)

Interesting observation there. Yes, at least for me DNS propagation issues have been rare lately, so it's easy to forget they can rear their ugly head unexpectedly, and can manifest itself seemingly strange ways.

Alinator

LOL...

No problemo, on the self reply. I would have saved you that 'embarassment', but I went to bed! ;-)

Interesting observation there. Yes, at least for me DNS propagation issues have been rare lately, so it's easy to forget they can rear their ugly head unexpectedly, and can manifest itself seemingly strange ways.

Alinator

Interesting things are happening on the net. The same host name is pointing to different addresses on successive uses, which is OK, but some of them are in unexpected places. Note the variety of addresses used for boinc2.ssl.berkeley.edu.nyud.net (http.l2.l1.l0.nyucd.net) below, particularly the one that went through Vienna, Austria. This was a bit of a surprise. There also seem to be some black holes in the mix, so it doesn't appear to be working all that well. Nothing to be done about it, just thought it was interesting to note.

Now, back to the day job.

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\\>ping boinc2.ssl.berkeley.edu.nyud.net

Pinging http.l2.l1.l0.nyucd.net [128.42.6.143] with 32 bytes of data:

Reply from 128.42.6.143: bytes=32 time=80ms TTL=52
Reply from 128.42.6.143: bytes=32 time=66ms TTL=52
Reply from 128.42.6.143: bytes=32 time=66ms TTL=52
Reply from 128.42.6.143: bytes=32 time=65ms TTL=52

Ping statistics for 128.42.6.143:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 65ms, Maximum = 80ms, Average = 69ms

C:\\>ping boinc2.ssl.berkeley.edu.nyud.net

Pinging http.l2.l1.l0.nyucd.net [138.15.10.55] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 138.15.10.55:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\\>tracert boinc2.ssl.berkeley.edu.nyud.net

Tracing route to http.l2.l1.l0.nyucd.net [143.205.172.12]
over a maximum of 30 hops:

1 23 ms 2 ms 1 ms x.x.x.x
2 16 ms 15 ms 15 ms x.x.x.x
3 24 ms 13 ms 12 ms cor01-vl-10.ca-sanfranc0.ne.earthlink.net [209.165.103.33]
4 21 ms 13 ms 12 ms bor01-ge-1-2.ca-sanfranc0.ne.earthlink.net [209.165.103.1]
5 26 ms 24 ms 27 ms ge-2-0.ipcolo1.SanFrancisco1.Level3.net [63.211.143.53]
6 26 ms 24 ms 25 ms so-6-1-0.mp2.SanFrancisco1.Level3.net [4.68.96.145]
7 27 ms 24 ms 27 ms ae-0-0.bbr1.SanJose1.Level3.net [64.159.1.129]
8 24 ms 24 ms 24 ms ae-33-89.car3.SanJose1.Level3.net [4.68.18.133]
9 26 ms 24 ms 24 ms 144.232.18.25
10 16 ms 17 ms 17 ms sl-bb25-sj-2-0.sprintlink.net [144.232.9.241]
11 16 ms 14 ms 17 ms sl-bb23-sj-15-0.sprintlink.net [144.232.3.249]
12 91 ms 92 ms 92 ms sl-bb25-rly-0-0.sprintlink.net [144.232.20.10]
13 91 ms 92 ms 92 ms sl-bb24-rly-12-0.sprintlink.net [144.232.14.149]
14 98 ms 99 ms 100 ms sl-bb23-nyc-10-0.sprintlink.net [144.232.20.182]
15 171 ms 172 ms 172 ms sl-bb20-par-11-0.sprintlink.net [144.232.20.44]
16 186 ms 187 ms 187 ms sl-bb21-fra-13-0.sprintlink.net [213.206.129.66]
17 199 ms 200 ms 199 ms sl-bb21-vie-3-0.sprintlink.net [213.206.129.122]
18 198 ms 200 ms 199 ms sl-bb20-vie-15-0-0.sprintlink.net [80.66.136.42]
19 198 ms 199 ms 200 ms sl-gw10-vie-14-0-0.sprintlink.net [80.66.136.35]
20 192 ms 192 ms 192 ms 80.66.143.6
21 192 ms 192 ms 282 ms Wien2.ACO.net [193.171.23.21]
22 196 ms 197 ms 197 ms Klu.ACO.net [193.171.12.198]
23 195 ms 197 ms 197 ms ubwcis.edvz.uni-klu.ac.at [193.171.18.18]
24 198 ms 199 ms 197 ms 143.205.170.1
25 199 ms 197 ms 200 ms plab2-itec.uni-klu.ac.at [143.205.172.12]

Trace complete.

C:\\>ping boinc2.ssl.berkeley.edu.nyud.net

Pinging http.l2.l1.l0.nyucd.net [152.2.130.66] with 32 bytes of data:

Reply from 152.2.130.66: bytes=32 time=118ms TTL=47
Reply from 152.2.130.66: bytes=32 time=99ms TTL=47
Reply from 152.2.130.66: bytes=32 time=99ms TTL=47
Reply from 152.2.130.66: bytes=32 time=98ms TTL=47

Ping statistics for 152.2.130.66:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 98ms, Maximum = 118ms, Average = 103ms

C:\\>tracert boinc2.ssl.berkeley.edu.nyud.net

Tracing route to http.l2.l1.l0.nyucd.net [128.151.65.102]
over a maximum of 30 hops:

1 16 ms 1 ms 1 ms x.x.x.x
2 13 ms 14 ms 12 ms x.x.x.x
3 21 ms 13 ms 15 ms cor01-vl-10.ca-sanfranc0.ne.earthlink.net [209.165.103.33]
4 24 ms 13 ms 14 ms bor01-ge-1-2.ca-sanfranc0.ne.earthlink.net [209.165.103.1]
5 24 ms 22 ms 22 ms bor02-so-3-1.ca-pasadena0.ne.earthlink.net [209.165.109.154]
6 23 ms 22 ms 22 ms bor01-ge-1-1-0.ca-losangel4.ne.earthlink.net [209.165.107.182]
7 21 ms 22 ms 24 ms eqix.lsan.twtelecom.net [206.223.123.36]
8 98 ms 97 ms 97 ms 66.192.240.226
9 * * * Request timed out.
10 96 ms 94 ms 94 ms cat6509-urmc-sb-c.net.rochester.edu [128.151.254.89]
11 96 ms 94 ms 99 ms cat6509-hopeman-d.net.rochester.edu [128.151.254.150]
12 96 ms 97 ms 94 ms planet2.cs.rochester.edu [128.151.65.102]

Trace complete.

C:\\>ping boinc2.ssl.berkeley.edu.nyud.net

Pinging http.l2.l1.l0.nyucd.net [128.42.6.144] with 32 bytes of data:

Reply from 128.42.6.144: bytes=32 time=78ms TTL=52
Reply from 128.42.6.144: bytes=32 time=62ms TTL=52
Reply from 128.42.6.144: bytes=32 time=64ms TTL=52
Reply from 128.42.6.144: bytes=32 time=66ms TTL=52

Ping statistics for 128.42.6.144:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 62ms, Maximum = 78ms, Average = 67ms

---

I struggled again with a new client. The host resolving stuff you guys were talking about.

I managed to get the files by imputing an open proxy to boinc : 200.171.124.197 3128

Try this, in case you struggle with this and get this thread by searching.

Please fix this, because its easier for new users to switch to other projects instead of debugging and scratching head for seti.

---

--
Øyvind

Hmmm...

Bad idea, IMHO.

If you find you can't get the app from Berkeley or its designated distribution proxy, then you're far better off to get it from a known entity like Joe Segur (who's graciously hosting it at the moment here) and unzip that into the project directory than routing through an unknown caching proxy in Brazil.

YMMV though.

Alinator

Well, after looking at it again, there is one thing that I had not considered. The redirect might be valid, but my DNS provider is having trouble with the host in the URL. And yes, that seems to be a real possibility, particularly since you say you can reach both URLs. Whois.internic.net says boinc2.ssl.berkeley.edu.nyud.net resolves, but Earthlink's name servers don't know it exists.

Called Earthlink tech support, spoke to a tech who ran me through

netsh interface ip delete arpcache
netsh winsock reset catalog
reboot
clear all the stuff in IE> Tools> Internet Options> General> Delete...

All to no effect. The tech could not resolve the nyud.net hostname, either.
Explained that the host resolves in whois, but not through Earthlink. Tech opened a ticket. I'll check it in the morning.

WHOIS has relatively little to do with DNS. It's a contact database so you can track domain owners down if needed.

The WHOIS database doesn't "resolve" anything.

To find this, a DNS resolver starts with one of the root servers (like a.root-servers.net). That refers .net queries to the GTLD servers (a.gtld-servers.net for example) and that returns a long list of nyud.net servers.

When you query one of those for boinc2.ssl.berkeley.edu.nyud.net, that returns a CNAME (right now boinc2.ssl.berkeley.edu.http.l2.l1.l0.nyucd.net), and with a CNAME that means DNS has to start over with the root.

Root, then GTLD, then the NYUCD servers, and ANOTHER CNAME, http.l2.l1.l0.nyucd.net.

... and at least that resolves.

This is a lot more work than just finding a name and being done with it.

-- Ned

---

Interesting things are happening on the net. The same host name is pointing to different addresses on successive uses, which is OK, but some of them are in unexpected places. Note the variety of addresses used for boinc2.ssl.berkeley.edu.nyud.net (http.l2.l1.l0.nyucd.net) below, particularly the one that went through Vienna, Austria. This was a bit of a surprise. There also seem to be some black holes in the mix, so it doesn't appear to be working all that well. Nothing to be done about it, just thought it was interesting to note.

Actually, they're trying to be very tricky in how they resolve to balance load across multiple servers.

They have a "TTL" of 30 seconds -- they're telling us that they're likely to change in the next 30 seconds.

More than likely, they're changing DNS to point at the least-loaded servers for fastest downloads -- but IMO they're pushing all this load from the web server to their DNS servers. I'm not surprised by the results.

---

Hmmm...

Bad idea, IMHO.

Alinator

You're right Alinator, it wasn't a very good idea. I tried another client today and I got stuck with checksum errors. Downloading from the link you guys have provided works much better.

It sure varies. :)

---

--
Øyvind

My computer at work was giving me the same message:
10/29/2007 9:50:03 AM|SETI@home|Temporarily failed download of setiathome_5.27_windows_intelx86.exe: can't resolve hostname

I downloaded the zipped file you people have posted here and it fixed problem:

10/29/2007 9:53:34 AM|SETI@home|File setiathome_5.27_windows_intelx86.exe exists already, skipping download

---