ICANN Offers Fix For Domain Name Collisions

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."

Re:Not much of a fix

[DarkOx]

Right,

There is a universal truth out there nobody, not even Vixie, fully understands DNS in terms of all its interactions with it self scaled globally and what assumptions (correct or otherwise) software that uses it makes.

I fail to see how this proposed behavior solves anything. Most software out there was written to assume that if you get back an address DNS resolution worked, if there was a problem you get back something like NXDOMAIN. Lots of apps are not going to report any problems if they get back 127.0.53.53, there are going to sit and wait for the connection to time out or depending on how the system is configured report connection refused. Leaving the user with no way to know the name was wrong.

Its not good for developers writing new code either, because now they have to do somethig like this:

Try addr = gethostbyname($hostname) //stupid hack to test for 127.0.53.53
raise NSException.NXDOMAIN if addr == aton("127.0.53.53")
dosomethingwithaddress(addr)
catch NSException => e
echo 'Name resolution problem' + e.msg >> $strerr
end

Which is ungly confusing and stupid.

Of course the real issue here nobody is taking care of is the security one. Bob is happily using his laptop to read his mail on the corporate network connected to mail.some_now_public_tld and then he goes to the coffee shop, the guys operating some_now_public_tld fixup their dns to answer for mail and wait for Bob to send his credentials. It will work too because Its a certain that the same folks who thought it was a good idea to ignore the rfcs and use some_now_public_tld are the same ones who still think its okay to run services with no authentication to the client. So Bobs mail app not configured to use SSL etc never checks any server cert and just sends his password.