[dspguru]

This is not directly related to the earlier thread about malicious spoofed DNS, but it's something very similar:

While looking for solutions to a VPN problem, I had occasion to ping one of our company URLs from my netbook, which I generally don't use for business puposes. The IP address resolved as expected, and the pings succeeded. I then pinged the same URL from my main working machine (I'm remote, actually very remote, from our main office) and on that machine I got a completely different IP address, also with successful pings. My other 'working' machine, used mostly to display schematics at my workbench, gave the same incorrect DNS resolution.

Running ipconfig with the /flushdns option brought up a message that the local DNS cache had been flushed, but subsequent pings still brought up the wrong address.

I can't publish either IP address, or our URL, on a public forum, but ARIN says the inappropriate one belongs to Shopatron, a company we had some dealings with last year. They seem to have found a way to make our URL resolve to their IP address, but only on these two machines.

Does anyone know how to fix this? Has anyone else seen this effect after using Shopatron's services?

[lunarlander]

check the hosts file on the affected PCs. The file is located in \windows\system32\drivers\etc\

If you suspect DNS poinsoning, disable the DNS cache service. DNS will still resolve, just that the results will not be cached.

[dspguru]

This problem has gone away. It's not really 'solved', but fixing the underlying OS problem also fixed this. I had to do a full system restore from a drive image, and now the DNS tables are clear, and a whole lot of other mysterious problems are fixed, too.

A word to the wise: Don't ever install a device driver while running the virtual XP machine in W7! You must install the driver in W7 itself, and let the W7 integration firmware handle linking it to the virtual machine. If you try it install it directly, the virtual machine may crash (presumably because the driver installer wrote to memory the XP emulation did not own) and both the virtual machine, and W7, may become unstable or completely unusable.

[DoubleHelix]

I'm not sure what device drivers or firmware you're talking about. I've been using Virtualization for years. The whole point is to have separation between the host and guests systems. I've never had or heard of a guest system crashing and bringing down the host. I had stability problems with VirtualBox several years ago and have not used it much since, but there should never be any problems with guest systems that affect the host.

[dspguru]

You should note that I was referring only to Microsoft's "virtual XP" software running under Window 7 64-bit version. I can't comment on any other form of virtualization.

But your assertion is correct. Virtual machines should run in a sandbox, which is why I spent the last couple of weeks beating on my IT support people because my VPN connection, amongst other things, had stopped working.

The USB device driver was provided by ST Microcontrollers, one of the largest manufacturers of microcomputers in the world. I suspect they know how to write a driver. Now that it is installed correctly in W7, it works perfectly.

Attempting to install this driver (it's a Windows DLL, of course) from inside the virtual XP window caused the virtual XP application to crash. Uninstalling and reinstalling the virtual XP application did not get it working again.

I suppose at that point I should have realized this had caused problems with the underlying OS, but, like you, I thought virtual XP ran in a protected environment. Apparently not...

The 'integration layer' is itself a special sort of driver. It allows the virtual machine to send and receive USB messages through the real USB software and hardware in the W7 PC. In virtual XP you activate it, on a device-by-device basis, using a menu in the virtual XP screeen. It is part of the 'sandbox'. It disconnects the W7 device drivers from W7 and re-routes them to the virtual machine instead, so there are no conflicts.

All of this works. What apparently does not work is installing a driver DLL directly into the virtual machine's memory space. When that is activated, it will try to access low-level hardware and software addresses which the virtual machine does not actually possess. At that point things can (and do) go seriously wrong. What should happen is an error message, or a forced shutdown of the whole protected virtual machine. That's what should have happened...