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."
I do hope they fix that (Score:1)
Dot Thirty (Score:5, Funny)
Re: (Score:2)
If you are going to use Roman numerals why not just host in the virgin islands?
Of course you might have users searching for info about their favourite text editor. :)
Re:Dot Thirty (Score:5, Funny)
The Virgin Islands TLD is ".emacs"?
Re: (Score:2)
TL;DR: (Score:5, Informative)
TL;DR: (Score:1)
What an ugly workaround
Re: (Score:2)
Or is this actually a good idea? It looks horrible to me.
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.
Re: (Score:2)
Re: (Score:2)
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, [...]
Oh, that's the problem right there.
You've assumed that because you know how to set things up correctly, everyone will set their DNS correctly.
Re: (Score:2)
Re: (Score:3)
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
Re:Not much of a fix (Score:4, Interesting)
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: (Score:3)
It should be connecti
Re: (Score:1)
Something like protocol://continent.country.service.domains.subdomains/directory/file.ext
But no one is going to put up with typing in na.usa.discussion-forums.technology.slashdot.askslashdot any more than they'd put up with typing in 216.34.181.48. Plus, it's a burden on users to assume that they'll know (or care, or remember) on which continent and in which country each site lives. So we'd need some system to translate your well-executed hierarchical taxonomy into something that users could more easily remember. I wonder what we could call it...
Re: (Score:3)
> 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_ whe
Re: (Score:2)
Couldn't the exact same thing be said for the admins that decided to use a TLD that wasn't explicitly reserved for internal use only?
Re: (Score:3)
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.
OR better... (Score:5, Insightful)
Re: (Score:2)
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: (Score:1)
Is there a list of guaranteed to never be used names? .local is not really that usefull for anything but the most simple LANs
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.
Re: (Score:2)
How about one- or two-character names that aren't used as or ever likely to be used as an international country code? I'm pretty sure ICANN's money grab still requires you to have at least a 3-character TLD.
Another idea would be (if you're just worried about hostnames, and search domains won't work for you) to do like those dodgy web sites that use $COMMONWORD$DIGIT$DIGIT.com and stick digits one one side or the other. If you're really hardcore and only have Dell equipment, you can use the service tag ID f
Re: (Score:2)
If you're really hardcore and only have Dell equipment, you can use the service tag ID for the machine name!
But how would that be limited to Dell shops? My employer runs mostly HP computers, each with a conspicuous serial number.
Re: (Score:1)
(plus as already mentioned, .local is for mDNS)
".test" and ".invalid" are reserved, but for special purposes hence not for general private naming (see RFC 6761).
".home", ".corp", and ".mail" are not quite "guaranteed", but ICANN currently intends to "defer delegating [them] indefinitely". See section 5 of the "NAME COLLISION OCCURRENCE MANAGEMENT" document.
Re: (Score:1)
So basically nothing usefull to anyone but a networking student doing a test network...
Re: (Score:3)
Re: (Score:3)
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... [ietf.org]
But
Re: (Score:2)
Forgot about x.org?
.org isn't a TLD?
Re: (Score:2)
Re: (Score:2)
ICANN should just reserve a TLD or two for private networks similar to how some IP ranges were reserved in RFC1918.>
Yeah, but who will be responsible for handing ICANN the annual briefcase-full-of-large-bills to pay for such a scheme?
Re: (Score:2)
As a business you register a domain from a TLD of your choice for US $10 or more a year.
Then you use that domain internally.
Re: (Score:2)
I should probably add:
most businesses probably have a public website.
Don't make the internal domainname the same as your website.
If you want to re-use the same domain, use:
office.domain.tld
Re: (Score:2)
But that actually has a fix without having to change everything (!):
set up your search path correctly.
external collisions? (Score:1)
I'd rather they release a tool to deal with the external TLD collisions.
I have a buddy that is a partner at "dot (x)". Back in the days when six bazillion TLD's weren't even on the drawing board, they poured some money into what they regarded as their cool new brand name in a subindustry of (x). At the time I thought, hey, cool, that's clever and not even descriptive. (I'm an IP lawyer.) But when it came to needing to pony up the couple million to try keep ICANN from handing out a .x TLD, of course they
Re: (Score:2)
I thought the whole thing was just a super-slimy way to raise a ton of cash off the backs of legitimate businesses... that chose stupid names for themselves.
Why do people use internal TLDs? (Score:2)
I still don't understand why people use their own strange TLDs internally. I always just use split horizon DNS, and put everything under the corporate domain name, thus eliminating the problem.
Why do people use internal TLDs? (Score:1)
For an intranet site that employees will be using hundreds of times per day, putting it on an internal petname TLD is much quicker to type. It's for user/admin convenience. And it wouldn't have been a problem had ICANN decided NOT to assert it's ownership of the entire TLD space - this also fucks up Tor hidden services, NameCoin, and GNS naming systems, which piggyback on special non-ICANN TLDs specifically so that existing protocols can be used over those systems.
Re: (Score:2)
For an intranet site that employees will be using hundreds of times per day, putting it on an internal petname TLD is much quicker to type.
This is why man invented search domains. Yeah, they don't support multiple levels of DNS, but if you're running something that does that, you're doing it wrong(tm)
Re: (Score:1)
Well, as you pointed out, it doesn't support multiple levels, so why are you suggesting this as a solution.
At my workplace we have thousands of hosts, so putting them on different levels based on function is essential to have manageable network. We use several TLDs each for a different data center with their own authoritative name servers. That way if for some reason certain data center is not reachable only names for that DC won't be resolveable instead of having the whole DNS infrastructure down.
We decide
Re: (Score:1)
Firstly ICANN didn't just assert ownership of the root. They inherited it along with the rest of the IANA.
And the administrators gambled that no one else would ever register that tld. Sorry they just lost that bet.
The DNS is designed to allow everyone to have their own namespace. To do this you need to register the name so that it can be uniquely yours. If you can't register it, don't use it. Period.
As for those protocols they could have requested a reserved name. They just failed to do so. There have
Re: (Score:3)
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 tak
Re: (Score:1)
They don't own you. However they are the authority for which names are added to the root zone. New TLD labels have always been possible and have been added from time to time.
The RBDMS vendors that squatted on a TLD were not rational actors. They knew or should have known that new TLDs could be added to the DNS at anytime. That new TLDS would be added to the DNS was published as part of the switch from a flat namespace to a hierarchical namespace. They failed to do due diligence. If they wanted a reser
Re: (Score:2)
They don't own you. However they are the authority for which names are added to the root zone.
They don't even own the root servers.
If ICANN continues to act in contravention of the best interests of the network there will eventually be consequences. Being an "authority" implies having obtained legitimacy. Acting recklessly and illegitimately for monetary gain undermines authority.
The RBDMS vendors that squatted on a TLD were not rational actors.
My example referenced reserved words rather than TLDs as an example of need for ALL sides to act rationally in potentially conflicted namespaces.
http://en.wikipedia.org/wiki/R... [wikipedia.org]
They knew or should have known that new TLDs could be added to the DNS at anytime.
Just because a namespace is conflicted do
Re: (Score:1)
Firstly ICANN had a black list of TLD labels that is wasn't going to allow anyone to apply for because they know they were likely to be in use.
If they looked at every "bad" TLD name that hit the root servers they could never add any new TLDs.
Having awarded contracts for TLD's they are try to minimise the impact on those labels that didn't make the black list or that they were unaware of.
Actually they do own and run one of the root servers. The company I work for owns and runs another of them. I submitte
Re: (Score:2)
Having awarded contracts for TLD's they are try to minimise the impact on those labels that didn't make the black list or that they were unaware of.
Minimization arguments are useless when there was never any articulable benefit to begin with. Selfish can't be justified no matter how hard you try.
That all being said they are the legitimate party to decide what gets added to the root zone.
If they keep it up they won't be.
Re: (Score:1)
"employees ... quicker to type"?
Seriously, that is a non-issue between bookmarks and auto-search in the browser/app/email client.
See also
Wrong solution to non-problem (Score:2)
by srg33 (1095679) on Monday August 18, 2014 @09:46AM (#47694499)
1. DNS will resolve locally first unless admin overrides. No problem. ["split horizon DNS"]
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 prob
Re: (Score:2)
" I always just use split horizon DNS, and put everything under the corporate domain name, thus eliminating the problem."
I have something like that at home, a registered domain name example.com and a portion *.home.example.com that was only resolvable from my lan.
Then, a few months back, I upgraded to the new Linux Mint LTS, which did all queries simultaneously to my ISP (fallback DNS) and my LAN DNS, using the first response. Sometimes the ISP was faster, resulting in 'nonexistent host' errors.
It took me a
1993 All over again (RFC-1935) (Score:5, Informative)
Thank you, ICANN, for returning to us a problem resolved in 1993.
See RFC-1535 [ietf.org]
Ehud
Re: (Score:1)
This isn't RFC 1535 all over again unless you are using partially qualified names where the end of the partially qualified name just happens to match one of the new TLDs. Partially qualified names have always been dangerous.
I just wish I had been able to convince Paul to break all existing use of partially qualified names back then by not appending search elements to any name with multiple labels. As much as foo.lab is convenient to type, foo.lab.example.net was safe as was foo + lab.example.net as a sear
Re: (Score:2)
The distinction is lost when the trailing period is left off.
NAME should in some search list match matching TLDNAME if one exists,
but the ambiguity if NAME exists in NAME.TLD (or, hello, name.GOBSofCCTLDS) let alone
NAME.subdomains.TLD means it's now a user problem.
The point of RFC-1535/1536 was to provide predictability in the resolver's traversal of its
available options. Computers are supposed to be predictable, predictive, and repeatable.
And yet... some domain resolver lookup yesterday may fail tomorr
Actual ICANN document (Score:5, Informative)
As usual, we have to go through two levels of blogs to get to the actual ICANN document. [icann.org] Which document you may find incomprehensible even if you know how DNS works.
Re: (Score:1)
Host your own DNS (Score:3)
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: (Score:3)
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.
Re: (Score:2)
Denying access as the default and explicit allowing exceptions is much more secure than the opposite.
Re: (Score:2)
Denying access as the default and explicit allowing exceptions is much more secure than the opposite.
Well no argument there but there are appropriate places to install filters and in appropriate ones. Its the job of the firewall to prevent connections to outside resources or possibly a proxy or gateway server, not the DNS servers because if the ip can be discovered some other way the control is bypassed.
Naturally in a high security environment you might need to control DNS. It can after all (at least with a cooperative) remote server be used for ingress and egress. You might configure an internal DNS se
Re: (Score:1)
Sure, that's true, but living in a dirt hovel in the desert armed with guns and knives, with no computer for a hundred miles around, is even more secure.
At some point people decide to make tradeoffs. A whitelisted internet (your suggestion) is good in one dimension (security) and bad in most of the others (primarily usefulness).
How to avoid being effected (Score:3)
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
My solution (Score:1)
I've been telling people that going to those odd top level domains are like calling 1-900 numbers, you will get a large bill from your ISP so just don't ever use them.
I gave up. (Score:2)
With the uncertainty of what I should use going in to the future and feeling like the ones that were set aside in RFC2606 didnt exactly apply (or were misleading) I broke down and gave all my internal hosts a world resolvable unique name.
it certainly makes for longer hosts... but at least I won't have to worry about this problem they made.
For internal non-routeable IPs I now use:
server.lan.example.com
and for stuff exposed to the net via world routable ip4 or ip6 i use
server.wan.example.com
I liked it before,
Re: (Score:2)
The way you're doing it is the only sane way to do it; using a registered domain under your control, for all internal naming.
Re: (Score:1)
How is this possible: "It took me hours" (Score:1, Redundant)
I have not clue how it could take someone HOURS to figure out the name was resolving incorrectly. It take SECONDS to run nslookup, with different nameservers on the TARGET MAACHINE. How is this even newsworthy? A network administrator that doesn't know what he is doing, takes hours to figure out that the name is resolving differently and we write an article on that?
How is this newsworthy?
Secondly, these other TLD's are the right of ICANN to implement. If we didn't want it, we didn't scream loud enough. What
Typo:How is this possible: "It took me hours" (Score:1)
Ugh - damn keyboard got stuck. In place of "I have not clue", please read as "I have no clue" :(
Lesson: Use registered domains for LANs (Score:2)
Avoid all this crap and just use a properly registered domain name (that you own and control DNS for!) as the most significant part of your FQDNs. You likely already own one for your business's Internet facing resources, but if you don't, spend $5 and get one. Set up public DNS for any Internet facing resources (www, mail, etc) and then use a subdomain of your choice for all your internal network's resources (fileserver.lan.mydomain.com, mediaserver.lan.mydomain.com, etc). No chance of collisions. Job done.
Wrong solution to non-problem (Score:2)
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).
Re: (Score:2)
Why doesn't ICANN just reserve such TLDs like .local or .lan for internal use in LANs? Then they can have mail.local, and whatever they want. I have .lan as a TLD in my private network at home, and I don't have a global dns hostname, and I don't want to use .test.
Re: (Score:2)
Thanks, didn't knew that!