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.