[X] My Assistant

[Bjorn Jonsson]

Has anyone had problems accessing www.unmannedspaceflight.com recently ? Since last weekend I haven't been able to access it from home but if I use a computer at work (as I'm obviously doing now ;-) ) there are no problems.

This is the only website I'm having any problems accessing so this is really weird.

[elakdawalla]

Has anyone had problems accessing www.unmannedspaceflight.com recently ? Since last weekend I haven't been able to access it from home but if I use a computer at work (as I'm obviously doing now ;-) ) there are no problems.

This is the only website I'm having any problems accessing so this is really weird.

I'm having no problems, but um3k emailed me earlier today to ask me the same question -- he can't see it either.

--Emily

[Bob Shaw]

I'm having no problems, but um3k emailed me earlier today to ask me the same question -- he can't see it either.

--Emily

Sounds like somebody's DNS server has gone sideways, somewhere...

Bob Shaw

[Bjorn Jonsson]

Weird - it works now for the first time since last Saturday (I'm sending this from home ). And I checked many times a day so the problem was probably 'continuous'.

EDIT: I don't think this was a DNS problem because I'm getting the same address for UMSF (72.9.234.170) as I got several hours ago when I couldn't get here from home.

[um3k]

It's working for me now.

[djellison]

I've not had any problem at any point from either work or home. It can't be a server problem as it was working for most people all the time. Perhaps some sort of routing problem in the 'net somewhere.

Doug

[Bill Harris]

Once in a while UMSF will "time out" and I'll get a "Page Cannot Be Displayed" message. I assume it's a 'net problem.

Could Bjorn's problem be a firewall at work? Or some network admin filtering non-work-related Internet addresses?

--Bill




EDIT: oops, I re-read the messge and the problem is at home.

I dunno...

[Bjorn Jonsson]

The problem has reappeared - I again cannot access UMSF from home. There have been intermittent errors from work as well but a 'Refresh' in IE usually gets rid of these.

Maybe a routing problem. Here is a portion of 'traceroute' I did when everything worked properly yesterday:

[Snip]
8 95 ms 83 ms 83 ms ae0-6.lon11.ip.tiscali.net [213.200.77.125]
9 50 ms 52 ms 50 ms so-3-1-0.lon22.ip.tiscali.net [213.200.80.30]
10 50 ms 83 ms 54 ms ldn-b2-link.telia.net [213.248.100.193]
11 59 ms 51 ms 50 ms ldn-bb1-pos0-1-0.telia.net [213.248.74.1]
12 618 ms 330 ms 368 ms nyk-bb1-pos0-2-0.telia.net [213.248.65.90]
13 306 ms 411 ms 281 ms ash-bb1-pos6-0-0-0.telia.net [213.248.80.69]
14 227 ms 194 ms 159 ms atl-bb1-pos5-0-0.telia.net [213.248.80.142]
15 154 ms 159 ms 159 ms globalnet-103907-atl-bb1.c.telia.net [213.248.90
.54]
16 150 ms 140 ms 138 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105]
17 172 ms * 173 ms gig0-1.l3-atl-5.gnax.net [209.51.131.94]
18 176 ms 172 ms 169 ms star.dnsprotect.com [72.9.234.170]

Now things look like this:

[Snip]
8 85 ms * 98 ms ae0-6.lon11.ip.tiscali.net [213.200.77.125]
9 * 52 ms 59 ms so-3-1-0.lon22.ip.tiscali.net [213.200.80.30]
10 51 ms 60 ms 62 ms lon-b2-pos1-3.telia.net [213.200.77.134]
11 83 ms 84 ms 83 ms ldn-bb1-pos0-1-0.telia.net [213.248.74.1]
12 142 ms 126 ms 128 ms nyk-bb1-pos0-2-0.telia.net [213.248.65.90]
13 187 ms 143 ms 130 ms ash-bb1-pos6-0-0-0.telia.net [213.248.80.69]
14 151 ms 147 ms 141 ms atl-bb1-pos5-0-0.telia.net [213.248.80.142]
15 143 ms 132 ms 120 ms globalnet-103907-atl-bb1.c.telia.net [213.248.90
.54]
16 128 ms 125 ms 117 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105]
17 134 ms 146 ms 149 ms gig0-1.l3-atl-5.gnax.net [209.51.131.94]
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.

Strangely I also get "Request timed out" at work but still can access UMSF...

[Guest_PhilCo126_*]

An interesting topic just to find out on which kind of server is UMSF running ?
a curious ITer on the continent

[djellison]

It's a package from www.imhosted.com

CODE

Operating system      Linux
Kernel version  2.4.21-27.0.4.ELsmp
Machine Type  i686
Apache version  1.3.33 (Unix)
PERL version  5.8.4
Path to PERL  /usr/bin/perl
Path to sendmail  /usr/sbin/sendmail
Installed Perl Modules  Click to View
PHP version  4.3.11
MySQL version  4.0.25-standard-log

Doug

[Bob Shaw]

The problem has reappeared - I again cannot access UMSF from home. There have been intermittent errors from work as well but a 'Refresh' in IE usually gets rid of these.

Maybe a routing problem. Here is a portion of 'traceroute' I did when everything worked properly yesterday:

[Snip]
  8    95 ms    83 ms    83 ms  ae0-6.lon11.ip.tiscali.net [213.200.77.125]
  9    50 ms    52 ms    50 ms  so-3-1-0.lon22.ip.tiscali.net [213.200.80.30]
10    50 ms    83 ms    54 ms  ldn-b2-link.telia.net [213.248.100.193]
11    59 ms    51 ms    50 ms  ldn-bb1-pos0-1-0.telia.net [213.248.74.1]
12  618 ms  330 ms  368 ms  nyk-bb1-pos0-2-0.telia.net [213.248.65.90]
13  306 ms  411 ms  281 ms  ash-bb1-pos6-0-0-0.telia.net [213.248.80.69]
14  227 ms  194 ms  159 ms  atl-bb1-pos5-0-0.telia.net [213.248.80.142]
15  154 ms  159 ms  159 ms  globalnet-103907-atl-bb1.c.telia.net [213.248.90
.54]
16  150 ms  140 ms  138 ms  atl-core-a-tgi2-1.gnax.net [209.51.149.105]
17  172 ms    *      173 ms  gig0-1.l3-atl-5.gnax.net [209.51.131.94]
18  176 ms  172 ms  169 ms  star.dnsprotect.com [72.9.234.170]

Now things look like this:

[Snip]
  8    85 ms    *      98 ms  ae0-6.lon11.ip.tiscali.net [213.200.77.125]
  9    *      52 ms    59 ms  so-3-1-0.lon22.ip.tiscali.net [213.200.80.30]
10    51 ms    60 ms    62 ms  lon-b2-pos1-3.telia.net [213.200.77.134]
11    83 ms    84 ms    83 ms  ldn-bb1-pos0-1-0.telia.net [213.248.74.1]
12  142 ms  126 ms  128 ms  nyk-bb1-pos0-2-0.telia.net [213.248.65.90]
13  187 ms  143 ms  130 ms  ash-bb1-pos6-0-0-0.telia.net [213.248.80.69]
14  151 ms  147 ms  141 ms  atl-bb1-pos5-0-0.telia.net [213.248.80.142]
15  143 ms  132 ms  120 ms  globalnet-103907-atl-bb1.c.telia.net [213.248.90
.54]
16  128 ms  125 ms  117 ms  atl-core-a-tgi2-1.gnax.net [209.51.149.105]
17  134 ms  146 ms  149 ms  gig0-1.l3-atl-5.gnax.net [209.51.131.94]
18    *        *        *    Request timed out.
19    *        *        *    Request timed out.
20    *        *        *    Request timed out.
21    *        *        *    Request timed out.
22    *        *        *    Request timed out.
23    *        *        *    Request timed out.
24    *        *        *    Request timed out.
25    *        *        *    Request timed out.
26    *        *        *    Request timed out.
27    *        *        *    Request timed out.
28    *        *        *    Request timed out.
29    *        *        *    Request timed out.
30    *        *        *    Request timed out.

Strangely I also get "Request timed out" at work but still can access UMSF...

Bjorn:

You get to star.dnsprotect.com [72.9.234.170] when it works, but don't when it fails. Sounds to me like somebody, somewhere, is going to a cached version of UMSF (sometimes). When it all works, it all works. When it fails briefly, the page gets (properly) refreshed next time. Try changing your DNS lookup to another DNS server - I'll post a list if anyone is interested.

Bottom line: trust not host services, or ISPs - they have the LIE flag set by default!

Bob Shaw

[mars loon]

Once in a while UMSF will "time out" and I'll get a "Page Cannot Be Displayed" message.

This "Page Cannot Be Displayed" has happened to me a few times today and other days usually while paging backwards. but its just occassional

[helvick]

Strangely I also get "Request timed out" at work but still can access UMSF...

Traceroute is getting to be quite unreliable these days on the big ole internet as many providers specifically block such traffic in order to prevent malicious entities mapping their infrastructure. Some systems block all ICMP traffic so even simple pings don't work but slightly smarter systems allow ping traffic but recognise and block Traceroute packets.

The problem as described would have me suspect the following (in decreasing order):
DNS problems - either the affected client has a DNS cache issue or its DNS servers have an issue dealing with some DNS change for www.unmannedspaceflight.com. That change might not be one Doug would ever be aware of - it could be a change in any DNS system between your DNS and the root DNS infrasture or between the point where www.unmannedspaceflight.com is registered and the root DNS servers.
If you are using XP the following command lines may help see\resolve the issue if it is client side\your DNS:
ipconfig /displaydns and nslookup
Shows the contents of your DNS Cache - specifically shows the host name and Time To Live (in seconds). The TTL shows the time left before your DNS will go back out and confirm the cached value of UMSF that it has. Nslookup <hostname> will show you the current ip-address your machine resolves <hostname> to.
ipconfig /flushdns
This will clear out your local dns cache and force your machine to carry out a lookup again. It wont help if dns servers are the problem but it's worth a shot.

A netblock ban being enforced by some entity between you and www.unmannedspaceflight.com. It happens to some folks more than others and depends mostly on how responsive your own ISP is to requests to cut off sources of known malicious traffic.

A failed\misconfigured load balancer close to www.unmannedspaceflight.com . The real nasty aspect of these is that unless you know how the load balancer in question actually works it can be very hard to identify. In the cases I've seen the problem will affect a subset of users and depends entirely on your ip-address. Sometimes it's block based (e.g. users from 172.44.22.x can get to the site but users from 172.44.23.x can't) and sometimes it's full-ip based (e.g. 172.44.22.101 can get to the site but 172.44.22.102 can't), sometimes it's a round-robin effect (you succeed on average 4 times out of five attempts on a 5 way load balancer with one failed node). These are fairly simple examples, current ip load balancer tech is pretty smart but when it fails it really can be a bugger for a customer to figure out.

AlertSite provide a nice minimal page with all the basic tools in one place that allow you to get the same tests from a different location (WebPage Performance\Ping\Traceroute\Whois\DNS lookup]
http://www.dnsstuff.com/ Provides a bunch of additional excellent stuff in a slightly less simple format. It's trace route clearly recognises that dnsprotect seems to suppress unwanted ICMP traffic.
Traceroute.org provides a dazzling array of potential source locations for carrying out a traceroute test.

[Bjorn Jonsson]

Now I'm again unable to access UMSF from home. Things worked briefly (for about a day) on Monday. This is getting seriously annoying but I'm not sure where (if anywhere at all) to complain...

If anyone else apart from me and probably um3k has had similar problems I'd really like to know.

I have tried flushing the DNS cache on my machine as suggested in the previous message but to no avail.

[MahFL]

Did you setup a hosts file ? If you did and the target ip address changed you may not be able to display the page.