Slashdot Mirror
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."
How else could I keep my private porn .xxx server on the office network. :/
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.
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
You could try stop using Roman numerals in favor of ".thirty".
OR better — they can shove the new TLDs so far up their ass that they choke on them.
I'd rather have the ICANN do something about all these domain marketplaces like SEDO which blatently redirect me to a page full of ads in case I just misspelled a single character.
Give me the option to receive a message that I probably misspelled the name of the site.
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.
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 couldn't afford it. It'll probably cost them an obscene amount just to keep people off of variations of dotx.x or x.x when it comes time to actually register second-level domains.
I thought the whole thing was just a super-slimy way to raise a ton of cash off the backs of legitimate businesses. What, we were running out of domain names?
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.
...si hoc legere nimium eruditionis habes...
Thank you, ICANN, for returning to us a problem resolved in 1993.
See RFC-1535
Ehud
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.
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.
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.
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
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.
it's a fully functional design flaw
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 search list element.
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, using .wan and .lan TLDs ..but who knows when some asshole is gonna get the rights to use those..
life goes on!
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 tomorrow because unrelated to
the domain in which NAME is being resolved, ICANN has alowed NAME. to be registered.
Ick.
E
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 is the point of all this chatter on this topic now?
Just curious why we don't have better stories to talk about. ICANN is old news. They're a broken organization that is trying to maintain order in a system that was never designed for centralized control.
Just my two cents.
I note (in passing) many, many major companies still can't DNS working properly, despite the tech being 30 years old.
Creating internal TLDs for a company was always a dumb idea. It's as if the network and DNS designers had never worked in IT, and were under the impression that things never change/could never change/would never change.
Inevitably the argument for these false TDAs was that they would never resolve to a real internet domain, and so protected the company from accidentally leaking infrastructure data. Other arguments were also made, regarding convenience and legibility had limited merit, but normally reflected the laziness or limited understanding of the people rather than any real benefit.
This mess is down to truncated thinking, chronic 'i-can-doism' (and no should-I-doism) from from network admins.
Ugh - damn keyboard got stuck. In place of "I have not clue", please read as "I have no clue" :(
What an ugly workaround
I use .tld as the end of internal domains and won't have to worry about collisions with external domains. I have noticed lots of organisations insist upon using .net for internal domains which seems particularly stupid.
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.
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).