ICANN Offers Fix For Domain Name Collisions 101
An anonymous reader writes with news about ICANN's fix for conflicting domain names. This kind of problem — when an internal server's DNS name conflicts with one of the new Top Level Domain (TLD) names — is going to start happening more and more often. With over 300 new TLDs available to be used by August 2014 and 1,100 more to come, you can expect to see it a lot. Fortunately, the Internet Corporation for Assigned Names and Numbers (ICANN) has a fix so you don't have to go through all the hoops I did to find the problem: the Name Collision Occurrence Management Framework. According to ICANN, which is also the organization that has blessed us with so many new TLDs to add to such old favorites of .com, .edu, and .org, "The framework is designed to mitigate the impact of name collisions in the DNS, which typically occur when fully qualified domain names conflicts with similar domain names used in private networks. When this occurs, users can be taken to an unintended web page or encounter an error message."
Not much of a fix (Score:5, Insightful)
So the solution here is that when someone looks up a domain that isn't registered, but uses a TLD that could be ... its going to resolve to a 127.0.53.53 ... and thats magically better than not resolving to a different site ... okay, but not by very much.
Second, they're going to postpone some TLDs that are 'popular' on private networks ... WHAT THE FUCK made you create these new TLDs in the first place? Did you just pull some TLDs out of your ass and say 'great plan' and only AFTER saying you would create them start to think about the impact?
What the hell kind of setup does this actually affect anyway? So you lookup an internal name only after you get an NXDOMAIN from a root server or something? I've not been a sysadmin/netadmin by profession in a few years, but in all the networks I manage (home, small office) we lookup names internally FIRST and if it doesn't exist internally, THEN it goes external, and the internal servers are AWARE of the location of servers for all internal names. If my internal servers aren't aware that corp.mail exists on server 10.69.4.2 then how the hell are they ever going to resolve it?
Pardon my out of date ignorance, but this really sounds pretty silly and adding a bunch of false resolves when there should be nothing more than an NXDOMAIN.
And for the record, most of these new TLDs are just stupid and never should exist. Either make it a free for all and get it over with with a few names reserved for internal use, or stop adding new TLDs willy nilly.
I'm shocked they didn't go ahead and add a .local TLD just to really fuck it up.
OR better... (Score:5, Insightful)
In other words (Score:5, Insightful)
The concept of reserved namespaces for host names no longer exists. *ANY* domain suffix used by a host in a private network can potentially collide with a current or future TLD from ICANN. Even if you carefully check all of your hostnames against ICANN's list today, that doesn't guarantee there won't be a collision six months from now.
Re:In other words (Score:4, Insightful)
Not to mention .local is used by IETF's ZeroConf (aka Bonjour) protocol to resolve using mDNS.
(It comes in handy on networks where the internal DNS servers don't accept registrations so your Linux machines can still be referenced using mDNS as if it was done regularly).
And well, on home networks that don't typically run DNS, well, mDNS makes it easy to find where that )(@*&%@)( printer is you just connected.