Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

ICANN Offers Fix For Domain Name Collisions

samzenpus posted about 2 months ago | from the jury-rigging dept.

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

cancel ×

101 comments

Sorry! There are no comments related to the filter you selected.

I do hope they fix that (0)

sadness203 (1539377) | about 2 months ago | (#47692387)

How else could I keep my private porn .xxx server on the office network. :/

Dot Thirty (4, Funny)

tepples (727027) | about 2 months ago | (#47692403)

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

Re:Dot Thirty (1)

ChunderDownunder (709234) | about 2 months ago | (#47692651)

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 (5, Funny)

93 Escort Wagon (326346) | about 2 months ago | (#47692839)

The Virgin Islands TLD is ".emacs"?

Re:Dot Thirty (0)

Anonymous Coward | about 2 months ago | (#47693173)

He said editor, not operating system.

Re:Dot Thirty (1)

tepples (727027) | about 2 months ago | (#47693861)

An operating system whose editor is called "Viper Mode", right?

Re:Dot Thirty (0)

Anonymous Coward | about 2 months ago | (#47695829)

The Virgin Islands TLD should really be ".eunuchs".

TL;DR: (5, Informative)

supersat (639745) | about 2 months ago | (#47692397)

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.

Re:TL;DR: (0)

Anonymous Coward | about 2 months ago | (#47692777)

That's not a fix. It makes things worse!

TL;DR: (1)

Anonymous Coward | about 2 months ago | (#47693241)

What an ugly workaround

Re:TL;DR: (1)

Zaiff Urgulbunger (591514) | about 2 months ago | (#47706545)

So does that mean that instead of affected organisations needing to fix the internal naming, now, every single piece of software that does a DNS lookup, now needs to check not only for not-found, but also 127.0.53.53 because it's magical?!

Or is this actually a good idea? It looks horrible to me.

Not much of a fix (5, Insightful)

BitZtream (692029) | about 2 months ago | (#47692399)

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 (0)

Anonymous Coward | about 2 months ago | (#47692457)

I'm shocked they didn't go ahead and add a .local TLD just to really fuck it up.

Heh, I skimmed the article looking for that one too.

Re:Not much of a fix (0)

Anonymous Coward | about 2 months ago | (#47692477)

Insert Coin to Continue

10... 9... 8....

why the reference to arcade machines? because it's all about the quarters they raked in without asking why... or should we do this?

Re:Not much of a fix (1)

TubeSteak (669689) | about 2 months ago | (#47692625)

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:Not much of a fix (1)

Noah Haders (3621429) | about 2 months ago | (#47692635)

i dont know what any of those words mean.

Re:Not much of a fix (2)

BitZtream (692029) | about 2 months ago | (#47692735)

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 (3, Interesting)

DarkOx (621550) | about 2 months ago | (#47693751)

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 (2)

tlhIngan (30335) | about 2 months ago | (#47695501)

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.

Re:Not much of a fix (0)

Anonymous Coward | about 2 months ago | (#47693245)

I'm shocked they didn't go ahead and add a .local TLD just to really fuck it up.

Considering that RFC 6762 (Multicast DNS) [ietf.org] has taken over .local already, making it a global TLD would be beyond stupid. RFC6762 could have used .mdns with hardly a chance of collision. The .local TLD was already in use on private networks, but I guess everybody wants a nice name.

Re:Not much of a fix (0)

Anonymous Coward | about 2 months ago | (#47693447)

To be perfectly honest, TLDs and the whole damn DNS needs to die. Horribly.

The newsgroup hierarchy is FAR better at organization and originally was going to be the system used until some retard had a stroke mid-meeting and shit all over everything that could have been. Then email had to be changed too.
It could have been improved considerably as well. Newsgroups system isn't exactly perfect.
And for local domains, you could ignore a section of the address up to country identifiers.
Something like protocol://continent.country.service.domains.subdomains/directory/file.ext
Best part is this can be extended both directions. Say we do end up living in space, or other planets, you could easily add those in, protocol://star.body.continent...
Let's say we meet some funky 4 dimensional beings, we could add that too. Then we find out the universe is one of many, throw that in too!

NOPE, instead we get the least important sub-domains on the left side of a domain, which only leads to abuse by websites mimicking other sites, such as http://google-com-maliciouswebsitehere.net.

At some point, we are going to have to take back the web. Who wants to make billions out of Web2. (not to be confused with Web2.0)
ICANN CANN get fucked. They have ruined the web.

Re:Not much of a fix (1)

ShaunC (203807) | about 2 months ago | (#47697549)

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:Not much of a fix (2)

Antique Geekmeister (740220) | about 2 months ago | (#47693675)

> 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 (1)

cdrudge (68377) | about 2 months ago | (#47693967)

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?

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:Not much of a fix (2)

BitZtream (692029) | about 2 months ago | (#47694135)

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... (4, Insightful)

Great Big Bird (1751616) | about 2 months ago | (#47692405)

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

Re:OR better... (0)

Anonymous Coward | about 2 months ago | (#47692949)

+10000000000000 omgpleasemakeitso

Re:OR better... (0)

Anonymous Coward | about 2 months ago | (#47697809)

Are you really okay with merely shoving it that far up their ass?

Re:OR better... (1)

jon3k (691256) | about 2 months ago | (#47698619)

Amen. This entire thing is the most transparent money grab by ICANN I've ever seen. And that's saying a lot.

Fix the real problems first! (0)

Anonymous Coward | about 2 months ago | (#47692409)

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.

In other words (5, Insightful)

Anonymous Coward | about 2 months ago | (#47692433)

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 (1)

Anonymous Coward | about 2 months ago | (#47692475)

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 (3, Insightful)

tlhIngan (30335) | about 2 months ago | (#47692751)

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 (0)

Anonymous Coward | about 2 months ago | (#47692757)

It is. You just have to uninstall/disable Bonjour...because its too late to beat any sense into them.

Re: In other words (0)

Anonymous Coward | about 2 months ago | (#47692891)

I know! .NET!

Oh... wait.

Maybe .LAN? I dunno.

Re:In other words (0)

Anonymous Coward | about 2 months ago | (#47693305)

The best thing to do, if you want to be guaranteed to never have a collision with a publicly-available domain name, is to register a domain name and make your internal network have its DNS inside that domain. That name is guaranteed never to be used on the public internet, unless its by you. And you can make it not available publicly if you want.

Search domains (supported by every resolving library I know of) will let you get away with not having to type "somehugeunregistereddomainname.guru" everywhere.

Re:In other words (1)

Megane (129182) | about 2 months ago | (#47693841)

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 for the machine name!

Re:In other words (1)

tepples (727027) | about 2 months ago | (#47695407)

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:In other words (1)

David Lee Lambert (2823693) | about 2 months ago | (#47695835)

(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:In other words (-1)

Anonymous Coward | about 2 months ago | (#47692491)

RFC2606
RFC6761

Re:In other words (1)

Anonymous Coward | about 2 months ago | (#47692533)

So basically nothing usefull to anyone but a networking student doing a test network...

Re:In other words (2)

Noah Haders (3621429) | about 2 months ago | (#47692645)

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 (2)

TheLink (130905) | about 2 months ago | (#47693137)

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

Re:In other words (0)

Anonymous Coward | about 2 months ago | (#47693289)

How about using 1-letter domain names? though not descriptive it gives us (at least) 26 local TLDs. But I guess I just jinxed that and some guy at ICANN is monetizing this in 3...2...1...

Re:In other words (0)

Anonymous Coward | about 2 months ago | (#47693759)

Forgot about x.org?

Re:In other words (0)

Anonymous Coward | about 2 months ago | (#47694019)

He meant TLD's, not domain names :)

Re:In other words (1)

YoungHack (36385) | about 2 months ago | (#47694127)

Forgot about x.org?

.org isn't a TLD?

Re:In other words (1)

tepples (727027) | about 2 months ago | (#47695421)

I read AC #47693289 as referring to something.w, anothername.w, etc.

Re:In other words (1)

petteyg359 (1847514) | about 2 months ago | (#47708707)

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:In other words (1)

Lennie (16154) | about 2 months ago | (#47694041)

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:In other words (1)

Lennie (16154) | about 2 months ago | (#47694081)

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:In other words (0)

Anonymous Coward | about 2 months ago | (#47695303)

That's not actually a fix for this problem. That is what every office I've worked in does, but they also set the search path so just "foo" resolves to foo.office.domain.tld. The problem is now "foo" may often be a valid tld.

Re:In other words (1)

Lennie (16154) | about 2 months ago | (#47695751)

But that actually has a fix without having to change everything (!):
set up your search path correctly.

external collisions? (1)

Anonymous Coward | about 2 months ago | (#47692463)

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?

Re:external collisions? (1)

wiredlogic (135348) | about 2 months ago | (#47692637)

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? (1)

Strider- (39683) | about 2 months ago | (#47692519)

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? (1)

Anonymous Coward | about 2 months ago | (#47692573)

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:Why do people use internal TLDs? (1)

Strider- (39683) | about 2 months ago | (#47692593)

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:Why do people use internal TLDs? (1)

Anonymous Coward | about 2 months ago | (#47693153)

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 decided to add a number at the end of the DCs name to future proof ourselves from ICANN's idiotic decision, though one might wonder how long it will take until they allow numbers in names as well.

Re:Why do people use internal TLDs? (1)

marka63 (1237718) | about 2 months ago | (#47692701)

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 always been processes to get reserved names.

Re:Why do people use internal TLDs? (2)

WaffleMonster (969671) | about 2 months ago | (#47692743)

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.

Re:Why do people use internal TLDs? (1)

marka63 (1237718) | about 2 months ago | (#47692805)

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 reserved name they could have requested one or heaven forbid registered one.

This is like vendors that squatted on 1.0.0.0 address space.

Re:Why do people use internal TLDs? (1)

WaffleMonster (969671) | about 2 months ago | (#47696397)

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 does not automatically follow it must not be utilized due to unpredictable future in which ICANN is driven by self-interest rather than the greater interests of the Internet community.

ICANN knew or should have known from volumes of negative feedback it received this would happen yet they failed to act conservatively and did so for selfish reasons. Even if it can be argued separately operators acted irresponsibly it does not absolve ICANN of irresponsible behavior. Grownups don't get to simply ignore the world as it is because they claim to have the "authority" to do so.

If they wanted a reserved name they could have requested one or heaven forbid registered one.

Absolutely people have nothing better to do than waste huge sums of money registering TLDs further enriching ICANN whenever they create a TLD for limited use within their administrative domain.

This is like vendors that squatted on 1.0.0.0 address space.

Dirty space is allocated responsibly by RIRs only after efforts to clean it or where scarcity induced pressure overrides the possibility of a more conservative policy. Toward the end operators ended up with crud from the bottom of the tank by design.

Up until exhaustion if you ended up with a dirty block you at least had the ability to "take it back".

Re:Why do people use internal TLDs? (1)

marka63 (1237718) | about 2 months ago | (#47699371)

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 submitted arguments, as a private individual, to not expand the root zone when this was being mooted. That all being said they are the legitimate party to decide what gets added to the root zone.

Re:Why do people use internal TLDs? (1)

WaffleMonster (969671) | about 2 months ago | (#47704861)

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:Why do people use internal TLDs? (0)

Anonymous Coward | about 2 months ago | (#47693243)

Period.

"Period" is not an argument. If you want to be taken seriously you should avoid using statements like "Period", stomping really hard in the ground or storming out and slamming doors.

Re:Why do people use internal TLDs? (0)

Anonymous Coward | about 2 months ago | (#47693379)

In my personal experience with women, periods are indeed an argument (drawn out over a few days).

Re:Why do people use internal TLDs? (0)

Anonymous Coward | about 2 months ago | (#47693111)

There's an RFC draft to cover exactly this.

https://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-02

Re:Why do people use internal TLDs? (1)

srg33 (1095679) | about 2 months ago | (#47695623)

"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 problem) or use myname.com.test (no problem).

Re:Why do people use internal TLDs? (1)

hankwang (413283) | about 2 months ago | (#47693031)

" 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 an hour to figure out what was wrong and how to repair it (networkmanager.conf, disable dnsmasq). Sigh. I wasn't the first to have this problem. The devs didn't really see the problem. https://bugs.launchpad.net/ubu... [launchpad.net]

Re:Why do people use internal TLDs? (0)

Anonymous Coward | about 2 months ago | (#47693455)

Not everyone is a corporation, a lot are private people with small private LANs on the ranges already reserved for that. We would use the TLD reserved for us but .local has post-assignment for this been re-delegated to mdns - so much for that guarantee.

1993 All over again (RFC-1935) (5, Informative)

gavron (1300111) | about 2 months ago | (#47692531)

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

See RFC-1535 [ietf.org]

Ehud

Re:1993 All over again (RFC-1935) (1)

marka63 (1237718) | about 2 months ago | (#47692885)

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.

Re:1993 All over again (RFC-1935) (1)

gavron (1300111) | about 2 months ago | (#47692977)

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

Actual ICANN document (5, Informative)

Animats (122034) | about 2 months ago | (#47692541)

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:Actual ICANN document (0)

Noah Haders (3621429) | about 2 months ago | (#47692655)

i put this on my blog but slashdot did not choose to link to that :( i dont know what their problem iz.

Re:Actual ICANN document (0)

Anonymous Coward | about 2 months ago | (#47692835)

meay b zay 4rt it waz sum miz spelt werdz. 0r may bee it wazent punchooated rite.

Host your own DNS (2)

Manfre (631065) | about 2 months ago | (#47692549)

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 (2)

DarkOx (621550) | about 2 months ago | (#47693941)

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:Host your own DNS (1)

Manfre (631065) | about 2 months ago | (#47693963)

Denying access as the default and explicit allowing exceptions is much more secure than the opposite.

Re:Host your own DNS (1)

DarkOx (621550) | about 2 months ago | (#47695191)

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 server to return records only for zone on which it is an authority and perhaps whitelist specific external zones like our.trusted.partners.com; but you certainly are not going to say allow it to resolve any .com and not any .mail|.food|.biz that makes no sense.

Re:Host your own DNS (1)

CauseBy (3029989) | about 2 months ago | (#47696797)

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 (2)

WaffleMonster (969671) | about 2 months ago | (#47692685)

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 slap my ballsack in protest (-1)

Anonymous Coward | about 2 months ago | (#47692771)

igduifhg

My solution (0)

thogard (43403) | about 2 months ago | (#47692837)

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.

That's not a moon (0)

Anonymous Coward | about 2 months ago | (#47692859)

it's a fully functional design flaw

I gave up. (1)

lemur3 (997863) | about 2 months ago | (#47692887)

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!

Re:I gave up. (1)

monkeyhybrid (1677192) | about 2 months ago | (#47694149)

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:I gave up. (1)

tomofumi (831434) | about 2 months ago | (#47701747)

you may also apply for an additional domain like example.net to host all your internal stuff too. Just like most ISP did.

How is this possible: "It took me hours" (1, Redundant)

passionplay (607862) | about 2 months ago | (#47693165)

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.

Typo:How is this possible: "It took me hours" (1)

passionplay (607862) | about 2 months ago | (#47693169)

Ugh - damn keyboard got stuck. In place of "I have not clue", please read as "I have no clue" :(

Internal TLD were always a dumb idea (0)

Anonymous Coward | about 2 months ago | (#47693167)

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.

Simple Solution (0)

Anonymous Coward | about 2 months ago | (#47693635)

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.

Lesson: Use registered domains for LANs (1)

monkeyhybrid (1677192) | about 2 months ago | (#47693947)

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 (2)

srg33 (1095679) | about 2 months ago | (#47694499)

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:Wrong solution to non-problem (1)

NotInHere (3654617) | about 2 months ago | (#47695037)

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:Wrong solution to non-problem (0)

Anonymous Coward | about 2 months ago | (#47695589)

.local is already de-facto used by zeroconf/bonjour, so it's pragmatic to avoid using it for explicit DNS zones.

Re:Wrong solution to non-problem (0)

Anonymous Coward | about 2 months ago | (#47695655)

.local is reserved already, see RFC 6762 section 22.1.

Re:Wrong solution to non-problem (1)

NotInHere (3654617) | about 2 months ago | (#47700145)

Thanks, didn't knew that!

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?