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

[BitZtream]

I can't actually figure out any setup where this will fix something without the admins of the network in question already knowing about the problem, obviating the need for this crappy hack in the first place.

I finally figured out the actual, though retarded, purpose.

You set up modified name servers, existing software doesn't do it .... When you query corp.mail (for example) and you have it internally, YOUR name server also checks for an external one in public DNS ... And then your resolver fucks EVERYTHING. Up by returning a local host address if there is both internal and external names, ignoring the problems that's going to cause in and of itself by returning loopback addressing.

This is absolutely retarded.

I can not possibly imagine a situation where this helps an admin. Anyone setting their network up to detect the issue is going to just RESOLVE (pun intended) the issue directly.

Re:Not much of a fix

[Antique Geekmeister]

> 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?

ICANN charges the registrars, and the registrars collect money for people registering their domains across all domains for simple fraud protection or trademark protection. I'm afraid that the domain registration business is aimed at the domain squatters, since they easily squat the domains _just_ when you try to register them and release them before they have to pay fees, if you don't follow up and buy them. The remainder that do get registered, and the defensive registration of the same name across multiple domains, is where ICANN gets funding.

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.

Re:Not much of a fix

[BitZtream]

Yes.

However, there are millions of admins of varying skill levels. ICANN is a small organization with individuals paid far more than they deserve that are supposed to know not only who these things work, how they are intended to work, how they are expected to work and how they are used in the real world.

ICANNs job is to take shitty admins into account when they do these things. Defacto standards can not be ignored, things like .mail are one of them, regardless of how stupid it was for someone to use them.

Re:Not much of a fix

[tlhIngan]

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.

It should be connection refused for most client systems. Because 127.0.53.53 is smack dab in 127/8 space - aka localhost space where all connections inside of 127/8 are supposed to resolve to itself, despite the actual IP used. For the few that have actual services in use (FTP, HTTP, etc), it's going to lead to a confusing mess.

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

[Noah Haders]

maybe somebody will get a TLD and specifically use it to block off for this purpose. i suggest .dong or .b00bz

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.

Re:In other words

[TheLink]

ICANN should just reserve a TLD or two for private networks similar to how some IP ranges were reserved in RFC1918. For example:
.private (broad scope - for internal/private use)
.here (narrower scope - limited to a particular location e.g. different starbucks outlets could be using whats.here and at each of those outlets it resolves to that specific outlet's stuff )
Feel free to think of other TLDs for private but different usage.

I actually proposed .here many years ago: http://tools.ietf.org/html/dra...

But seems they were too busy approving "Yet More Dot Coms" (e.g. .biz, .info etc).

That's one of the reasons I have a low opinion of ICANN. Anyone in the field could see this problem years ago, but they have done little to help and maybe even made things worse.

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.

Host your own DNS

[Manfre]

The easy fix seems to be to have your own internal DNS servers that block any conflicting TLD. If it's not on .com, .net, .org, or on a country TLD, then it's probably not worth visiting.

Re:Host your own DNS

[DarkOx]

Right so we can repeat the problems where dip shit network admin decided to not read any documentation and used something other than RFC1918 address space for internal routing. Now Bob in customer service is trying to get to the clients website which happens to be in the same IP range internal hosts uses, and wonders why he can't.

Seen it. You can't just exclude conflicting TLDs because sooner or later someone might need a resource on one of those tlds.

How to avoid being effected

[WaffleMonster]

Step 1: Do not blindly delegate * to root servers or upstream DNS provider on systems you control.

Step 2: Tell ICANN to go fuck itself

Re:Why do people use internal TLDs?

[WaffleMonster]

Firstly ICANN didn't just assert ownership of the root. They inherited it along with the rest of the IANA.

ICANN does not own me or anyone else. They can't force anyone to participate in their global experiments.

And the administrators gambled that no one else would ever register that tld. Sorry they just lost that bet.

I don't think there is anything wrong with making rational assumptions about the future. I gamble on the expectation RDBMS vendors act rationally with regards to staking claim to any new reserved words or system vendors to refrain from exercising their right to make irrational changes to APIs that would break everyone's software.

In this case it is clear ICANN is NOT a rational actor. Thankfully it takes little effort to opt out of their little experiment.

Wrong solution to non-problem

[srg33]

1. DNS will resolve locally first unless admin overrides. No problem.
2. ".test" is already the designated solution. See RFC 2606 and RFC 6761. It may not be pretty but it is RESERVED for this case.
So, either DNS works for myname.com LOCALLY (no problem) or use myname.com.test (no problem).