Internal Network Device Resolving to 127.0.53.53

Today I had a client call and tell me that, all at the same time, all of his Windows XP workstations wouldn’t load their dental software. Now this is weird, because his Windows 7 machines still worked just fine. This is a new client that we took over, so its not setup to our standards. Its a small office with one server and twelve workstations. Nothing too fancy. Server name is SERVER and domain is DENTAL.LOCAL

My initial thought was networking equipment failure. All of his XP workstations are right next to each other so I figured they might be on their own switch. However, they all still had internet. My next thought was maybe a software update broke the installation on XP only. But they hadn’t done an update in a few months, so that couldn’t be it either. So I started digging…

All of the mapped drives to the server were disconnected. When I tried to re-connect them, they gave me authentication errors, even with correct credentials. After a reboot, still no network drives. So then I thought, maybe they can’t talk to the domain controller anymore. So I tried a ping. This is where the fun starts.

Pinging the server by name got me a response from 127.0.53.53. WHAT?!

Nslookup was giving me a non-authoritative response of the same address from the server I’m trying to look-up by name. This doesn’t make any sense.

Checked local IP settings. Correct.

Flushed DNS cache. No dice.

Checked pinging and nslookup from a Win 7 workstation. Perfect responses.

A quick google search of 127.0.53.53 told me that ICANN uses that to let sysadmins know when they have a name resolution conflict. The only problem with that is, I didn’t have a conflict. DNS server on the server was setup perfectly. SOA, forwarders, and DNS entries were all correct. No errors in event log.

ICANN couldn’t have reserved .local, could they?

That’s when I had an epiphany. Even though .LOCAL wasn’t a gTLD, .DENTAL was. The XP machine were chopping off the .LOCAL from the end of the FQDN so they were trying to resolve SERVER.DENTAL.

I manually added the SERVER entry to the hosts file and they immediately started working again.

Guess its time to upgrade Doc.

Panasonic KX-TVA50 USB Drivers

Recently, we picked up a client that had a voicemail/phone system setup by another IT provider in what seems like the early 1900’s. However, it works and if it ain’t broke, don’t fix it.

Everything was fine until the computer that they used to control the voicemail system (Windows XP) died and we replaced it with a new Windows 7 machine. We were lucky enough to still have the old install disc for the voicemail system so we managed to get the software to interface with the system installed without issues. The software worked great but couldn’t talk to the Panasonic unit via the USB cable. Turns out, it needed drivers. No problem, right?

Wrong. Panasonic is very controlling about their drivers. In particular, phone system drivers. Their website offers none. Their customer support live chat can’t help with phone systems. Their toll-free number requires a dealer and tech code to even speak to a human for support. Since we aren’t a Panasonic reseller, we couldn’t get drivers from them. Even using the Google machine turned up nothing aside from a few telecom companies that wanted you to pay to have them install the drivers for you. Luckily, I know a few phone service companies in the area and one of them sent me over the drivers for it.

So I offer to you a, hopefully, easier way to find these drivers if you ever find yourself needing them.

Panasonic KX-TVA50 USB Drivers – 424KB – For: Windows 2K, XP, Vista, 7, Server 2003, Server 2008