Old IP caching problem

B

bro

Perch
I have a client who's still having a problem with one of their domains from a couple of the PCs on their network. They can't access www.theirdomain.com from those machines, but can from other machines on their network. Other domains of theirs on the same JH server are working fine.

If they ping (or tracert) 'www.theirdomain.com' they get the old 64.*** IPs returned (then no response, obviously), but if they ping 'theirdomain.com' they get 204.*** IPs, and they respond fine.

They've tried ipconfig /flushdns on every machine on the network, no use.

All the machines use the same internet connection, so it doesn't seem to me that it would be an ISP caching problem.

Where would it be? How the f*** do they fix it?
 
I have seen that happening to my own services domain. My solution to that issue was to sleep on it. Seriously. 8 hours later all old cached values died out and both: domain.com and www.domain.com were resolving properly.

What you can also do is to use "nslookup" utility from command prompt (present in winxp and win2k). Just call it:

nslookup domain.com

and

nslookup www.domain.com

That should tell you what DNS server does given machine use to resolve names and result of name-to-ip resolution. That should shed some light on the issue. Good luck.

One more thing - I noticed that ipconfig /flushdns does not always work. It happened twice to me on winxp that I ran the ipconfig command and then had to restart the computer anyways. In both cases that was after several days (well over a week) of constant work without restart, so I concluded that someting goofed up and never gave it second thought. Also I believe that browser itself has its own little cache. Hence, you definitely have to restart the browser after running ipconfig.
 
This has been like this since the IP changeover a few weeks ago, so I doubt waiting another 8 hours is going to help much... they've done ipconfig /flushdns more than once, deleted all their temp files, and reset all their PCs, too.
They've even thumped the monitor a couple of times and said 'stoopit f***** piece of s***' very loudly at it, but that didn't help either.

I'll get them to do the nslookup, anyhow, see what it says.
 
I missed the timeframe part. Couple of weeks is too long for any value to be cached. It must be something more permanent. I have two more ideas:

1. I would check the file:

C:\WINDOWS\system32\drivers\etc\hosts

this is the file where you can explicitely indicate name/ip association. It is the file without an extension. Open it in notepad. You can probably delete all unremarked lines except

127.0.0.1 localhost

2. If your client uses the network with Windows 2K (or newer) Server configued to be a domain controller, most likely there is a DNS server enabled on that machine. That server may be misconfigured. I have seen unexperinced technicians giving a name to a local domain identical as their internet domain even though they hosted their sites elsewere. Just a thought.

BTW, hitting the monitor with a juicy curse always works for me... better than for the computer though... ;)
 
what you can also do is go to the system32/drivers/etc/ directory and edit the host file

There you can enter each of the domains having an issue along with their new IP in this format:

domain1.com newip1
domain2.com newip2

That will force the domains to resolve to the new IPs..
 
That's nice as a temporary solution, but I'd take them out as soon as you solved the underlying problem. Who knows, the IPs might change again sometime and you'll have a nasty time tracking down why it isn't working on those machines :)
 
In case anyone had a similar problem to this, it was eventually resolved: The hosts file did not appear to exist anywhere on the network. Checking the network properties on each machine, one win98 and one XP machine had nameservers listed under Network properties/Enable DNS as 192.168.0.1 and an external nameserver that may have belonged to their PC repair company. Changing these to the ISPs nameservers fixed the problem on the XP machine, but did not fix it on the windows 98 PC. It appears that it always looked up 192.168.0.1 anyway, even though it was no longer listed, and it always returned the old level3 IP for the site. They weren't able to figure out which part of the network was 192.168.0.1. It's not any of the workstations or the fileserver. (Perhaps it's the broadband router..?)
Changing the nameserver IP to 192.168.0.6 (another machine on their network) fixed the problem.
So I'm still no wiser...
 
Hi, I am new here but I think I can help on this.
Our company had the very same problem for over 2 months. I contacted the ISP server, looked in the host file, flushed the DNS, and even tried to mess around with one-to-one NAT but I had no success.

After a terrible long time, I finally figured out what was going on. In our case, all I had to do was change the TCP/IP settings on the network connections (either VPN or local area connection, depending on how you get to your network).

1. Click in the ?Advanced? button

2. Make sure that the "use default gateway on remote network" is unchecked (General Tab)

3. Select "Append primary and connection specific DNS suffixes" in the DNS tab.

4. Still in this tab, check "append parent suffixes of the primary DNS suffix" and "register this connection's address in DNS". Leave "Use this connection suffix in DNS registration" unchecked.

That did the trick for me.

Good luck!
 
You must log in or register to reply here.
Back
Top