A user here at work borked one of their Windows 7 virtual machines after installing a VPN client and making some DNS/hosts changes.  There uninstalled the VPN client (something from SonicWALL) but the issues persisted.

IPconfig had some interesting clues, but some external sites were also having intermittent issues: sometimes gmail or google or amazon would or would not work.  This seemed DNS related.

Nonetheless, I wanted to eliminate the possibility that the VPN hadn’t left something altered.  I thought perhaps there was something related to the NIC so I removed and re-install the NIC drivers.  This did nothing.

My co-workers insisted I remove the virtual NIC and add another in its place.  I insisted killing the driver was a sufficient test, but since they kept going on about it I killed the virtual NIC just to silence them.  This did not work: it neither fixed the issue nor did it silence my helpful audience.

My admittedly brilliant network-guru boss even kicked me out from my terminal to hack away at it for a bit.  I wasn’t able to wrestle my desk back until the user in question asked for his machine back and I insisted I had to leave for the day.  I resolved to fix it first thing in the morning.  Sometimes a fresh perspective is all you need.

That and some gardening, I suppose.

Anyway, the next morning I went to work on one of the suggestions of my co-workers by trying to find some sort of removal tool for the already-removed VPN client.  In doing so, I noticed two things that started working in the back of my mind.  First, DNS resposes sometimes included an incorrect fully-qualified suffix.  Second, I was seeing the IP address of 127.0.53.53 for this VM.

I found this article on the IP address 127.0.53.53 and discovered that this was in fact a sort of error message.  In short it’s your network complaining that there is some degree of name collision happening.  This strengthened my position that it was a DNS issue.

I abandoned the whole un-installer nonsense and started poking around the network preferences.

If you open your network connections, you can find at least one connection to follow along.

Here you can see both your IPv4 and IPv6 entries.  You may want to check both of them (future proof?).  Anyway, pick one and click the Properties button.

Nothing much to see here.  Just head directly to that Advanced button.

Here is the meat.  This is where you control your DNS suffixes.  This is default.

Funny thing, Windows has two radio button choices for how to deal with DNS suffixes.  The first reads “Append primary and connection specific DNS suffixes”.

The second reads thus “Append these DNS suffixes (in order):”.

The interesting thing to note is the total lack of reference to the primary suffix if you choose the list.  You must include the primary (and any connection specific) if you use the second option.  His list did not include them.

Long rabbit hole with a simple solution.  I added the (in our case one) primary suffix at the top of the list and corrected the local access issue.