I got both right now. This is a Verizon hookup, and both sites are masked with security redirects in end routing-- and end servers are not responsive to traceroutes.

I can say this, the folding.extremeoverclocking.com page says it is updating stats, and has a semilocal route with an IP followed by a three part URL in its traceroutes.

Idea, give it 24 hours, sounds like a strange route issue on their end, like someone is working on router close to that site. The www.extremeoverclocking.com site is not responsive to traceroute either right now, a router might be masking deliberately the route, and I suspect the end node site server might be being used for work in web recovery by owner also, so you might have hit a time when he was checking his router or when he was using it to check his sites as an admin.

The other thing you can do if this persists, since one computer is hardwired, is to hardwire the other if feasible-- for a test. Your own router can set the DMZ inside of its wireless ports and if it was power-downed it might have come up partly at default and might not be feeding DNS outside itself quite right. The very oddball end address of the last two traceroute entries on hops 17 and 18 for folding.extremeoverclocking.com shows it was kludged and I suspect if you tell the admin these results he will know what is up and get it fixed, or Verizon will normalize routing later.

traceroute hops 17 and 18 (tracing from Florida, ignore latency):

17 unknown.Level3.net (63.210.132.78) 58.453 ms 59.274 ms 58.176 ms
18 242.152.171.66.subscriber.vzavenue.net (66.171.152.242) 60.388 ms 57.942 m
s 57.897 ms

8 next hops no response to traceroute, aborted after hop 26.

(note, I am not using Windows command of tracert, I am on a hardened Linux box here so I use traceroute as literal command call with site name after.)

The other site is not on the same region of Verizon, and I think actually a hosted site in Western US but not West Coast.

John, who thinks this might be routing hardening fluke, to ignore for 24-48 hours even if the problem has been that long, as Verizon is probably patching its own stuff and working around routing that normally woudl be used to let patches be applied offline on things serving normal routes, adn to block ports they can sometimes pull routers in this kind of attack to stop worms and IRCBOTS (like w32.randex.e 's bot, this is also an RPC DCOM worm (source Symantec and Microsoft in KB 826955 which is new MS KB for Blaster and includes links to w32.randex.e info on Symantec and the Blaster standalone fixer (FixBlast.exe) which is really only a ~140K dedicated Blaster, Blaster.b, and Blaster.c fixer), but affects all computers XP and Earlier other than IIS if not virus protected and for some if not firewalled) from propagating to some places at the routers.