Home network randomly cannot load pages from certain domain

This has been bugging me for quite some time now, forgive the long post.

Home network: DSL, Netgear Wireless G router, all client machines running WinXP Home/Pro SP1/SP2. Computers are using both wireless and landlines, outage described below happens regardless of connection method.

Long version
I have a site hosted via www.HostPC.com and I have already asked them about this issue. What happens is this: My domain will not load on our home machines but if I go anywhere else (including work), it loads just fine. I have tried this with a roommate over the phone while he's at my desktop and I'm at work simultaneously.

According to HostPC, it is a problem with our router/DSL. The thing is, I can most times load my site (www.weegs.com) and check my smtp mail, but for some reason or another, I will no longer be able to load the site nor check my email randomly and from that point forward until I power off the DSL modem and router at the same time. Also, both hostpc/weegs fail to respond to ping.

No other sites on our network have this problem. I can visit this site, cnn.com, google.com, and check my other smtp/web mail accounts just fine. The only solution I have for this random outage is resetting the DSL/router by taking the power cord out and in again. And during this outage, NO other computers on our network can load/ping hostpc/weegs sites. So it's not just my machine.

All I want to figure out is a starting point, I don't necessarily need a solution because that's how frustrated I am!! It's gotta be the DSL/router/host but I can't figure out who because they all say it's the other. Netgear has said it's the DSL, vice versa, etc.

Short version
Randomly unable to visit/ping site www.hostpc.com/www.weegs.com on our home network. This happens on all client machines. The only way to solve the issue has been to power off/on the DSL modem and router. Where do I start??!

 

First I'd suggest you try connecting to the site via the IP address rather than the DNS name. http://199.237.53.20 seems to be approriate (following looking at the results of pinging www.HostPC.com). If you can get to the site (or a least the web server hosting the site), this will tell you it isn't and underlying TCP/IP problem.

I expect that you will be able to get to the server this way (but perhaps not see what you expect to see). If that is the case it is DNS that is the problem and you could perhaps fix the problem by adding the line:

199.237.53.20 www.HostPC.com

To your Hosts file (in the Windows or WINNT folder).

What is your local domain set up as? The phenomenon you are describing is very reministant of networks where the local domain has been set up with the same name space as the internet domain (in your case Hostpc.com). If this is the root of the problem, it occurs because your DNS server sees www.Hostpc.com as an internal resource rather than an address out on the internet. You can fix that by creating an A record for www, in your hostpc.com tree.

 

I think the solutions ReggieB gave you should sort out the problem.

One expansion -
c:\windows\drivers\etc\hosts or
c:\winnt\drivers\etc\hosts

 

Today I came home from work and had to power off/on the router and DSL modem. I was able to check email and view the sites on the first try. Two hours later, I tried again, and the site fails to load. Again, all other sites load just fine.

ReggieB - Thanks for putting the IP in your response. I am unable to load the site by IP, nor does the site respond to ping. My computer is not set to a domain, but rather, it is set to a Workgroup: HOME.

Newt - I am unable to find that folder on my machine (running XP Pro, SP1). I do not even have a folder called drivers under my Winnt tree. Should I add this in?

I'm not sure if you guys are assuming I have a server setup somewhere in my house. Our simple network is as such: DSL modem conntects to router, three PCs connect to the router and that's it. We also use ZoneAlarm on each of our machines, but during the outages, I have closed that program and it still fails.

Thanks for the help.

 

If you can't ping the site by IP, then this is not a DNS name resolution problem.

I'm not sure what to suggest. The fact that you can browse other sites, demonstrates that it is not a basic set up problem ..... unless, you are also using 199.x.x.x as your internal address space (seems unlikely).

Check firewall settings and give your ISP's technical support a call.

What do you get if at the command prompt you enter:

tracert 199.237.53.20

The result might give us a clue as to where the problem is occurring.

 

PDubs - my goof and sorry.

c:\windows\system32\drivers\etc\hosts or
c:\winnt\system32\drivers\etc\hosts

 

Easy mistake to make Newt. It's not an obvious path. To be honest, I always find the HOSTS file by doing a file search of the Windows (or WINNT) folder. If you confine the search to that folder, the system picks up HOSTS pretty quickly.

Also another good example of why you should switch off (deselect, remove the tick from) the "Hide extensions for known file types" in explorer's folder options (under the view tab). HOSTS in a list of search results is easier to find when you realise it is one of the few files on a system that does not have an extension.

 

Reggie - tracert 199.237.53.20 yields the following:

C:\>tracert 199.237.53.20

Tracing route to www23.hostpc.com [199.237.53.20]
over a maximum of 30 hops:

1 removed - Newt
2 removed - Newt
3 removed - Newt
4 8 ms 9 ms 8 ms bb2-g1-0.austtx.sbcglobal.net [151.164.20.226]
5 15 ms 15 ms 14 ms bb1-p5-2.rcsntx.swbell.net [151.164.243.13]
6 15 ms 15 ms 14 ms bb2-p6-0.rcsntx.swbell.net [151.164.191.122]
7 15 ms 16 ms 16 ms ex1-p2-0.eqdltx.sbcglobal.net [151.164.40.33]
8 15 ms 15 ms 16 ms sl-st20-dal-4-0.sprintlink.net [144.228.250.109]
9 16 ms 15 ms 15 ms 144.232.8.122
10 41 ms 41 ms 41 ms p16-0-0-0.r01.atlnga03.us.bb.verio.net [129.250.4.195]
11 * 54 ms 53 ms p16-2-0-0.r00.atlnga03.us.bb.verio.net [129.250.5.16]
12 * 68 ms * p4-0-2-0.r01.bcrtfl01.us.bb.verio.net [129.250.4
.54]
13 68 ms 68 ms 68 ms ge-1-2.a01.bcrtfl01.us.ra.verio.net [129.250.24.34]
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 etc...through the remaining 30 hops.

Trace complete.

Interesting results. I know that the HostPC servers used to be in Atlanta and they recently (a few months ago) moved them to Floriday. They let their userbase know this due to the multiple hurricanes.

Newt - Thanks for the clarification, I should have searched before responding last time! I have added the line. Before doing so, the only contents in that file (besides the comments) was the localhost item.

Guys, I also wanted to mention that after sitting on this for a day, I took out the router from the equation. This morning, the outage happened again, and I directly connected to the DSL modem without turning it off first. Worked just fine!! I then put the router back into the equation and I'm back to my outage again. Grr...but at least the problem appears to be with the router yah?

Thanks again for the continued help.

 

nm...I just found out the router was restarted. But with the recent frequency of outage, I should be able to further test by Fri night. That probably explains why the tracert worked.

 

PDubs,

Is that tracert route consistant - that is does it alway give the same (or very similar) list of addresses, and fail at about the same point? If so, I am confident that the problem is not with your router, nor even inside your network.

Looking at the path taken, it looks to me that the communication is almost getting to its final destination. I expect the problem is either with DNS set up at your ISP, or more likely is a problem with the set up of the system used by the company hosting the problem website.

I would recommend sending a copy of your TRACERT results (with a covering note describing your problem) to the tech support departments of both your ISP and the people hosting the problem website. The fact that the communication packets are getting out of your network and being routed around the internet is a clear indication that the problem is not with your system.

There is a possibility that the problem is an intermittent fault on your router. I would expect this to result in inconsistant TRACERT results, and would effect all sites note just one. Therefore, I think this is a less likely cause of your problem.

 

I've done a little further investigation. This is my TRACERT result (with first few lines missing):

8 860 ms 700 ms 919 ms 213.181.59.142
9 599 ms 1009 ms 558 ms cbu-pcbru21-pecbru21-pos124.car.belbone.be [213.181.58.37]
10 892 ms 652 ms 578 ms sl-gw10-bru-10-0.sprintlink.net [80.66.129.89]
11 890 ms 1513 ms 735 ms sl-bb20-bru-8-0.sprintlink.net [80.66.128.45]
12 1219 ms 725 ms 1012 ms sl-bb22-lon-13-0.sprintlink.net [213.206.129.41]
13 1625 ms 683 ms 1063 ms 213.206.131.86
14 1011 ms 654 ms 1417 ms p16-0-0-0.r80.nycmny01.us.bb.verio.net [129.250.5.91]
15 1051 ms 869 ms 958 ms p16-0-1-3.r21.nycmny01.us.bb.verio.net [129.250.2.170]
16 882 ms 1241 ms 1632 ms p16-1-2-2.r21.asbnva01.us.bb.verio.net [129.250.4.27]
17 936 ms 1016 ms 837 ms p64-0-0-0.r20.asbnva01.us.bb.verio.net [129.250.2.34]
18 * 1008 ms * p16-0-0-0.r00.atlnga03.us.bb.verio.net [129.250.2.49]
19 * 1100 ms 986 ms p4-0-2-0.r01.bcrtfl01.us.bb.verio.net [129.250.4.54]
20 1135 ms 696 ms 880 ms ge-1-2.a01.bcrtfl01.us.ra.verio.net [129.250.24.34]
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.

The start is a little differnet, because I'm coming from the other side of the Atlantic, but I stall at about the same point. Verio.net appear to be a web hosting outfit. I presume they are hosting your site. I think the problem is at their end. Contact verio.net tech support first.

 

Also, if you can still edit your posting, delete the first three lines of your TRACERT result.

 

I'm having the exact same problem with PDubs. In talking to the owner of hostpc I've determined the following:

1. Traceroute is normal (firewall doesn't pass pings on one of the Verio hosts)
2. Non-pingability of the host is also normal (see above)

Does not seem to be a DNS issue, since I have the same problem if I try to connect directly to the IP.

Anybody found a solution to this yet?