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

Comments

TL;DR:

[supersat]

127.0.53.53 will be returned when a collision is detected. AFAICT this means when you query DNS for a non-existant 2nd level domain in one of the new TLDs.

Not much of a fix

[BitZtream]

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.

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.

Dot Thirty

[tepples]

You could try stop using Roman numerals in favor of ".thirty".

Re:Dot Thirty

[93 Escort Wagon]

The Virgin Islands TLD is ".emacs"?

OR better...

[Great Big Bird]

OR better — they can shove the new TLDs so far up their ass that they choke on them.

In other words

[Anonymous Coward]

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

[tlhIngan]

Is there a list of guaranteed to never be used names? .local is not really that usefull for anything but the most simple LANs

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.

1993 All over again (RFC-1935)

[gavron]

Thank you, ICANN, for returning to us a problem resolved in 1993.

See RFC-1535

Ehud

Actual ICANN document

[Animats]

As usual, we have to go through two levels of blogs to get to the actual ICANN document. Which document you may find incomprehensible even if you know how DNS works.