NOTE: this post is directed at IT Pros and contains information and terms that may make non IT Pros roll their eyes, tune out, or make their heads explode.
I ran into an interesting problem at one of my clients the other day. It was new to me, and the root cause seems relatively new to the Internet – less than a year, though it appears to have been under development for longer than that. The symptom was that users on the network were unable to open the multi-user Quickbooks file from the server. The root cause was that Cisco had registered a new top-level domain name.
Sounds strange, but it’s all based on a relatively recent initiative by ICANN (Internet Corporation for Assigned Names and Numbers) to avoid Name Collisions on new TLD’s (Top Level Domains). As such, legacy TLD’s such as .com and .net are likely not affected (and are unlikely to fall victim to TLD collision in the first place). But if you use any domain that matches one of the new TLD’s as the default domain on your local network (like say, “NINJA”), you might run into this problem as well.
In my customer’s case – a small shop with a few computers in a workgroup – they had a Cisco router (RV220W) configured as the DHCP and DNS server for the network. When workstations get an IP address from DHCP, they are also provided with a default domain, which tells the client machine what domain to append to the end of unqualified hostnames. In this case, the factory-configured default domain was “cisco” (go figure). So whenever they try to connect to “SERVER” (which is just a hostname), the system appends the default domain to make it “SERVER.cisco”. Before the new TLD “.cisco” existed, this would just fail. And yet, because the workstations in this workgroup environment have been relying on NetBIOS or LLMNR or mDNS, everything’s been working fine. For the past six months anyway.
About two months ago, Cisco registered “cisco” as a new TLD (like .com). And they configured it (I guess very recently) to prevent namespace collisions as per the ICANN guide (sections 3.1 and 3.2). Now whenever my customer’s router was asked to resolve “SERVER.cisco”, it forwarded the request to the nameservers for the new “.cisco” domain, which in turn responded with the namespace collision IP address of 127.0.53.53, which is a legitimate response (not a failure). So of course this broke the internal network. By design!
127.0.53.53 is exactly what I saw during my troubleshooting that led me down the path to resolution. Every internal host responded with this IP address. It’s a wildcard DNS entry on new TLD’s that has a singular purpose of breaking internal networks (see section 3 in the above-mentioned guide) in order to spur admins into doing something to prevent the namespace collision.
I have lingering questions as to whether Cisco knew that it would break some of its customer’s internal networks, and whether this initiative even solves a problem that needs to be solved. Regardless, if you ever see internal hosts resolving to 127.0.53.53 – now you know why.