DNS is not the issue. Per a screen shot that Memski posted
here, the browser clearly states 'Waiting for reply...'. This means it has managed to connect, but for what ever reason, the TCP session is then being screwed up.
If was to guess at what this issue is, it feels like an MTU problem/mismatch. I can't be sure though. If I do 2 traceroutes with packet sizes 1500 and 1501, I get this:
| Text |
1
23
45
67
89
1011
1213
1415
| # traceroute -nI 46.38.178.219 1500
traceroute to 46.38.178.219 (46.38.178.219), 30 hops max, 1500 byte packets...
7 92.52.76.246 30.004 ms 32.120 ms 34.588 ms 8 92.52.77.95 36.878 ms 38.965 ms 41.214 ms
9 46.38.178.219 41.885 ms 41.925 ms 41.949 ms# traceroute -nI 46.38.178.219 1501
traceroute to 46.38.178.219 (46.38.178.219), 30 hops max, 1501 byte packets...
6 195.66.226.116 22.364 ms 24.576 ms 26.999 ms 7 92.52.76.204 30.588 ms 32.935 ms 35.315 ms
8 92.52.77.95 37.863 ms 40.063 ms 42.362 ms 9 * * *
10 * * *11 * * * |
This is suggesting that the server does not like fragmented packets, and fragmentation is linked with MTU mismatches. I get the same result with
www.google.com, never had any issues there. And
www.bbc.co.uk seems perfectly happy with large fragmented pings.
Though one very weird result of the above (which I have just noticed as of writing) is that hop 7 is actually a completely different IP address depending if the packet size is 1500 or 1501 - anyone ever seen that before? This anomaly (if indeed it is one) resides clearly in the realm of RackSpace hosting (their network).
I'm not suggesting this is the issue btw, but everything else so far in this thread has been ruled out, and I have seen no mention of MTU, so figured I'd throw this out there anyway incase anyone has further ideas.