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 Considers Using '127.0.53.53' To Tackle DNS Namespace Collisions

samzenpus posted about 8 months ago | from the that-doesn't-look-right dept.

The Internet 164

angry tapir writes "As the number of top-level domains undergoes explosive growth, the Internet Corporation for Assigned Names and Numbers (ICANN) is studying ways to reduce the risk of traffic intended for internal network destinations ending up on the Internet via the Domain Name System. Proposals in a report produced on behalf of ICANN include preventing .mail, .home and .corp ever being Internet TLDs; allowing the forcible de-delegation of some second-level domains in emergencies; and returning 127.0.53.53 as an IP address in the hopes that sysadmins will flag and Google it."

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

hacky (4, Insightful)

dmitrygr (736758) | about 8 months ago | (#46355123)

Seems like a very hacky solution...

Re:hacky (5, Funny)

DrPBacon (3044515) | about 8 months ago | (#46355133)

ICANT think of anything better.

Re:hacky (5, Funny)

Anonymous Coward | about 8 months ago | (#46355169)

ICANT think of anything better.

ICANN!

Re:hacky (0)

Anonymous Coward | about 8 months ago | (#46355823)

If anyone can, ICANN can

Re:hacky (0)

Anonymous Coward | about 8 months ago | (#46356025)

Assuming it involves enough industry 'incentives' of course

Re:hacky (2, Insightful)

Anonymous Coward | about 8 months ago | (#46357037)

Here's a better solution
Refuse to resolve any of the new gTLDs. Start petitions and stuff get you isps to refuse to resolves them. Get distros to patch their networking code to refuse to resolve them. Make them worthless.

Re:hacky (3, Interesting)

hcs_$reboot (1536101) | about 8 months ago | (#46355219)

That solution is indeed hacky. But if the LAN is correctly setup, the collisions should be minimal. I.e. on a "home" workstation, named something like "linux.home", that very station identifies itself and if the other LAN members communicate with "linux.home" an entry is supposed to be already present in "hosts" (like) files - and, usually, "hosts" file resolution takes precedence over DNS. For bigger implementations a DNS server or equivalent should be in place, and forward the unknown domains to external (Internet) DNS - again, their local config should contain an entry for the ".home" zone, preventing an external resolution.

Is returning 127.0.53.53 instead of NOT FOUND a good idea? Not sure about that, since, for instance, a browser will say "Cannot connect to..." instead of "Domain not found" - which is actually the correct error message. The real problem is when the domain+subdomain exist on the Internet, users will process information from the wrong site instead of the intranet one

Of course all IT teams will have to be DNS competent - which is currently not (always) the case ...

Re:hacky (2, Insightful)

Anonymous Coward | about 8 months ago | (#46355277)

What makes you think that a browser getting a 127.0.53.53 won't return a meaningful and very descriptive error? It is a special case worth flagging if ever their was one.

Re:hacky (4, Interesting)

DarkOx (621550) | about 8 months ago | (#46355991)

Right its a good idea to expect every application developer everywhere to put a special case test into their code see if the value in the buffer after a call to gethostbyname is 127.0.53.53 rather than just checking the return code and using the value directly or not based on the return code. Doing this means a new branch in every new app, for no real reason; It means odd behavior in old/not updated code that expects to either successfully resolve and address or not.

Case in point someone introduced a hostname into our DNS recently that caused a major application to break. Turned out there was a stale config entry for a hostname that no longer existed. As long as it had been getting back NXDOMIN things hummed along nicely, it just tried the next host in its list from a config file. When someone added that name back it, it started trying to connect to the new server ( which did not run the application it was expecting and did not listen on that port ) this would cause long timeouts on login while it tried and retried the other server. I grant this was a configuration error, someone should have cleaned that old config file, but there are situations like laptops where this might not be the case. Inside your organization .mail might exist as a zone, take the machine home and CustomAPP might work fine today getting NXDOMIN and switching to a local database or trying a different public hostname etc, now its going get back 127.0.53.53 and quite likely not know what to do; when the service isn't there.

No its patently stupid for the name resolution system to return BAD data. If something like .mail is not allocated or de-alocated than it does not exist, and NXDOMIN is what a public DNS system should return. The meaning is clear.

Re:hacky (2)

Antique Geekmeister (740220) | about 8 months ago | (#46356045)

It's spelled NXDOMAIN, by the way.

NXDOMAIN has not been a reliable response for invalid DNS queries for roughly 15 years. Look into the history of the "*.com" DNS entry in Verisign's root servers for the .com domain, which were returning valid Verisign owned hosts. And look carefully at the DNS proxy setups of major home network services, which often return their domain sales web pages instead of "NXDOMAIN" for invalid DNS entries.

Given that the data has _already_ been corrupted, this seems a reasonable attempt to broaden what is now done with "example.com". It also has the benefit that it's not auto-activated in default Kerberos configurations, a bit of behavior that genuinely alarms me in most default Kerberos setups and which few configuration tools have the ability to remove.

Re:hacky (1)

MichaelSmith (789609) | about 8 months ago | (#46355297)

DNS server or equivalent should be in place, and forward the unknown domains to external (Internet) DNS - again, their local config should contain an entry for the ".home" zone, preventing an external resolution.

Yeah but legitimate queries for the external linux.home won't work.

Re:hacky (5, Interesting)

DarkOx (621550) | about 8 months ago | (#46355921)

The problem really isn't so much not being able to reach some.home, on the internal network or even something.home on the Internet when you already have a local .home. zone.

The problem is all the uncounted config files out there with unqualified or partially qualified names in them. The RFCs are not entirely clear on what the correct behavior is, and worse the web browser folks have decided to implement the behavior differently themselves in some cases, rather than use the system nss services/apis.

So if you imagine an environment where DHCP configures a list of DNS search suffixes, and one of those is something like us.example.com or something. How the Windows boxes interpret a query mobile.mail (note no trailing dot) will possibly be different than the way the Linux machines do, and different than what the OS X machines do, etc and what Chrome or Firefox decide to do might be different than what nslookup does even on the same machine!

Its going to be nightmarish from a support and troubleshooting perspective, and lets face it nobody on your PC tech team really understands DNS, your network admins probably have a good handle but some major blind spots, and your developers are accustomed to making what are now dangerous assumptions. I am not sure I fully understand DNS on most days.

This is going to be a support nightmare at least at some sites, even some places where the ONLY sin was not using FQDNs everywhere all the time. Which might have deliberate, perhaps not the best way to have gone about it but knowing how search domains operate, and being able to set them with DHCP is entirely possible and like someone architect-ed mobile systems getting a local resource by depending on that behavior.

There are all kinds of potential security problems too. The gTLD expansion is making the Internet both less reliable and less safe.

Re:hacky (1)

WaffleMonster (969671) | about 8 months ago | (#46355317)

But if the LAN is correctly setup, the collisions should be minimal.

I'm sorry the Internet is a production network. Time for amateur hour expired with the 20th century. We don't get to make assumptions out of ignorance anymore.

Is returning 127.0.53.53 instead of NOT FOUND a good idea? Not sure about that, since, for instance, a browser will say

When I type http://127.0.53.53/ [127.0.53.53] into my browser I get a web site hosted on my computer. The entire 127/8 acts as a loopback not just 127.0.0.1. Quite a bit more problematic than "Cannot connect to..."

Re:hacky (4, Insightful)

hcs_$reboot (1536101) | about 8 months ago | (#46355381)

I'm sorry the Internet is a production network. Time for amateur hour expired with the 20th century

I'm sorry, I feel the time for amateur hours exploded in the 21th century. Competency was diluted among the many so-called experts answering the huge demand of engineers. It seems in bigger companies IT management is confined to ensure IT services work fine - meaning in most cases implement the fewer changes as possible - "don't fix what isn't broken". Most teams are not used anymore to hacking, customizing, improving, innovating. When something a bit trickier than usual rears its nose on the horizon, they're lost. DNS implementation is one of these trickier thing.

Re: hacky (0)

Anonymous Coward | about 8 months ago | (#46355671)

Answering the call for engineers or "web developers"?

Re:hacky (1)

jawtheshark (198669) | about 8 months ago | (#46355347)

if the other LAN members communicate with "linux.home" an entry is supposed to be already present in "hosts" (like) files

Host files? Are you serious? Nobody outside the tech world uses those and even the techs don't use it except for very very specific cases. For the normal users there is DNS-SD (Zeroconf) and anybody more technical is better off simply setting up a DNS server with authoritative zone for the local network (Which is why I hate these new TLDs... My domain of choice might be sold someday and I'll have to give it up using locally... having to use the boring .local or .home), with the added benefit of having a real DNS server on site becoming totally independent of the ISP DNS (well, unless you want to make a forwarding one).

This is a problem of their making. The generic TLDs shouldn't ever have been introduced.

Re:hacky (1)

therealkevinkretz (1585825) | about 8 months ago | (#46355743)

If you have a local authoritative server, why will you have to give up your local domain? (unless you actually want to access the new rightful owner's network)

Re:hacky (1)

jawtheshark (198669) | about 8 months ago | (#46355817)

Why? Because it's only authoritative for the local domain of course. I do also have public authoritative DNS servers, but I don't want them to serve private IP addresses. So, at home my domain is called simply "sharks" (buying that goes like, what? 50k€). It is not public, but authoritative locally. Now, of course, I could take one of the domains I own, and use that. I don't really like that idea. My hosts are named after shark species, so you have mako.sharks, hammerhead.sharks, etc... mako.jawtheshark.com really isn't the same.

Perhaps it makes it slightly clearer. Contrary to popular belief, an authoritative server does not need to be authoritative for the public internet. Locally is just fine. Just don't use stuff that clashes with the public DNS system.

Re:hacky (1)

jawtheshark (198669) | about 8 months ago | (#46355831)

I need to read better. You understood fully what I meant... The possibility of a clash is real and very very annoying.

Re:hacky (4, Interesting)

Anonymous Coward | about 8 months ago | (#46355369)

It may not even say "Cannot connect to". 127.0.53.53 is in the 127/8 range, reserved for localhost. On some systems, only 127.0.0.1 works for localhost, but nothing prevents a system from using the entire range for localhost.

So rather than getting an error, when server1.here lacks a host file entry for server2.here, you will be connecting to server1.here. So, from server1.here, "ping server2.here" will show that the network works. Browsing to "http://server2.here/" will show the start page of server1.here. If that's the default page, or the two servers are being setup to run some kind of load balancing - thus having the same content - the resulting confusion can be very hard to figure out.

Re:hacky (1)

jafiwam (310805) | about 8 months ago | (#46356051)

Returning 127.0.53.53 makes a lot of sense if you put up an ad-farm parking page on it to make a bunch of fake money with ad impressions.

Double bonus points when the "service" gets sold to a bottom feeder who's ad-network gets infected, ending up trying to spread viruses with fake "you are infected!" pop up windows.

Re:hacky (3, Insightful)

Stalks (802193) | about 8 months ago | (#46356475)

How do you put up a parking page that listens on loopback?

Re:hacky (2)

janeuner (815461) | about 8 months ago | (#46356991)

How do you put up a parking page that listens on loopback?

By sitting in a board room without any clue where your money comes from.

Re:hacky (4, Insightful)

fuzzyfuzzyfungus (1223518) | about 8 months ago | (#46355331)

Once you start down the dark path... Forever will it dominate your destiny.

It's not as though TLDs were ever a particularly shining moment in the history of information classification; but, after the remnant factions of the Ontology wars (remember when URLs were totally going to express useful data about the world and whatnot by being insufferably long and hierarchical?) retired or were driven into hiding, they mostly slumped, if more by erosion than sound structural engineering, into a vaguely safe and predictable structure.

And then they decided that it was just sickeningly adequate as it was and they started grafting on... things... things that should not be...in places that out not to have things there. Nothing could possibly go wrong. And oh boy, does it look like it will, good and hard.

Re: hacky (0)

Anonymous Coward | about 8 months ago | (#46356605)

This entire proposal makes no sense and sounds like a bunch of clueless morons sat around a table and discussed it, when their techs asked or answered their questions they dreamt up some clueless answers thinking they may have understood the issue when in reality the entire decision was out of ignorance.

Return NXDOMAIN for bad data, even -if- it is an emergency (if it's a massive DDOS they aren't going to do new DNS lookups, it's already cached!)

Don't prevent new tlds just because some idiot used it internally at mega-corp. assign the fucker TODAY and direct they to a web server with the bloody RFCS telling them how stupid they are and to fix their problem, not make it ours.

resolv.conf (1)

Rosco P. Coltrane (209368) | about 8 months ago | (#46355147)

search mydomain.com
nameserver 127.0.0.1

There, problem solved.
No need to say thank you...

Re:resolv.conf (2, Funny)

Anonymous Coward | about 8 months ago | (#46355231)

I'm using MSDOS, you insensitive clod!

Re:resolv.conf (1)

0xdeaddead (797696) | about 8 months ago | (#46355337)

wattcp has been around for ages. Like, seriously, where have you been? http://www.vogons.org/viewtopi... [vogons.org]

Re:resolv.conf (2)

rvw (755107) | about 8 months ago | (#46355607)

wattcp has been around for ages. Like, seriously, where have you been?

http://www.vogons.org/viewtopi... [vogons.org]

He clearly needs to reconfigure his extended memory.

Re: resolv.conf (1)

AvitarX (172628) | about 8 months ago | (#46355923)

Yay, now there's an entire TLD you can't access.
I worked at a small business where the previous admin had read about 1/3 of every sentence about networking I think (the internal networks were 192.1.1.0, 196.1.1.0 and 196.0.0.0 (all /24), eventually it was a problem.
To be fair, it was in '98, and he was self taught.

emergency! emergency! I say (0)

Anonymous Coward | about 8 months ago | (#46355157)

forcibly de-delegate google.com immediately. Its existence is offensive.

emergency response options (4, Insightful)

Anonymous Coward | about 8 months ago | (#46355173)

In addition the report recommends emergency response options, which will be employed only in situations "where there is a reasonable belief that the DNS namespace collision presents a clear and present danger to human life".

In other words, the DNS will be used for political oppression.

Re:emergency response options (0)

Anonymous Coward | about 8 months ago | (#46355191)

DNS will be used for political oppression.

It must be American-made!

Obsolete (0)

Anonymous Coward | about 8 months ago | (#46355195)

The IP/MAC addressing scheme it hacked to death already. How many protocols are used to get a single packet to its destination now? 50-100 or more? It's unfortunate that a better tiered scheme wasn't chosen to begin with, but with only a dozen or so nodes who knew it would grow to such an extent. If it where designed today, it'd be drastically different in architecture.

Re:Obsolete (0)

Anonymous Coward | about 8 months ago | (#46355209)

You don't know what a protocol is, do you?

Re: Obsolete (0)

Anonymous Coward | about 8 months ago | (#46355259)

Sure I do... Try ARP, TCP, DNS, IP, ETHERNET, 802.xx, MAC, BGP, HTTP (to get the port number).... Randomly tossed out there, it goes on and on and on... Most convert between PHY hardware layer, but still IP has dozens of adressing and routing protocols? Do you know what a protocol is?

Re: Obsolete (0)

Anonymous Coward | about 8 months ago | (#46355283)

Oh my god! Ethernet and MAC are protocols!?!? Holy crap I best relearn the way things work!

Re: Obsolete (3, Funny)

aichpvee (631243) | about 8 months ago | (#46355351)

Boy, boy, stop fighting with yourself.

Re: Obsolete (0)

Anonymous Coward | about 8 months ago | (#46355403)

For some reason I though of my first fight with Tyler.

Re: Obsolete (0)

Anonymous Coward | about 8 months ago | (#46355363)

Ethernet, 802, and MAC are the same thing. So that's a list of nine protocols with three redundancies. The only way you're going to involve more than a hundred protocols to get a single packet to its destination is by introducing a whole lot more ignorant redundancies. I know! Let's say HTTP and HTTp and HTtp and Http and http are all different things, too!

Re:Obsolete (2)

Jesrad (716567) | about 8 months ago | (#46355287)

Or maybe you don't understand this other AC's point ?

For example, combining the addressing into the naming method, instead of externally tying 4-byte of IPv4 adressing with host/domain names with a ad-hoc protocol. See IPv6's capability to have addresses made of letters, and push it a little further ? Then maybe even nest some routing hints into that data. Eck, include some multicasting capability at that point too, if you can. Once you start reconsidering the whole IP addressing and routing, surely there are a few better ways to name and address machines and route data to those addresses, which would make more sense at the current scale and form of the Internet. Might as well question the principle of maintaining a shared namespace in the first place instead of letting nodes make up their own (and sharing these namespaces, or fractions of those namespaces, between each other), too.

Re:Obsolete (0)

Anonymous Coward | about 8 months ago | (#46355383)

A layered model of networking protocols works just fine, thanks. But if you're interested in redesigning things, the English language is kind of old. It must be obsolete! Combining letters to make words is too much trouble. Surely there must be a better way, such as some kind of series of meaningful grunts. We can call it hipster grunt protocol. Grunt! Grunt! Grunt! Grunt! Grunt!

Re:Obsolete (3, Informative)

DarwinSurvivor (1752106) | about 8 months ago | (#46355409)

See IPv6's capability to have addresses made of letters, and push it a little further?

You mean hex? That's just the way you type it, it has NOTHING to do with the actual packets. For instance, slashdot's IP (216.34.181.45) could just as easily be written as "d8.22.b5.2d", or even "d822:b52d".

We just switched from decimal to hexidecimal for IPv6 notation because the addresses are so much longer now (IPv4 is up to 15 characters in decimal, IPv6 would be up to 63 characters if we used decimal (only 39 in quad-character hex).

Re:Obsolete (1)

Buck Feta (3531099) | about 8 months ago | (#46355551)

(IPv4 is up to 15 characters in decimal, IPv6 would be up to 63 characters if we used decimal (only 39 in quad-character hex).

v4 is 32 bits, v6 is 128 bits (not 15 and 63). v6 is 32 chars in hex, if not dropping zeroes. Otherwise, a good post.

Re:Obsolete (1)

Buck Feta (3531099) | about 8 months ago | (#46355559)

Never mind,my reading comprehension is not good right now. Too late.

Re:Obsolete (1)

Sique (173459) | about 8 months ago | (#46355867)

With the : between groups of four characters, you have to add 7 chars, and 32 becomes 39.

Re:Obsolete (1)

thogard (43403) | about 8 months ago | (#46355837)

Early ip resolver libraries would sometimes parse octal ip addresses with commas as in your example of /.'s ip address as 330,42,265,55. Many of those would also deal with a 0xd822b52d or sometimes without the 0x. Many systems will let you do something like "ifconfig en0 0xd822b52d/32 alias"

Some of the early proposals to expand the IPv4 address space was to allow use more of the bits from the ports source and destination addresses so you could do things like "ping 8.8.8.888" or "ifconfig en0 8.8.8.8/32/13/2 dstbits 4 srcbits 8"

Re:Obsolete (2)

davidhoude (1868300) | about 8 months ago | (#46356139)

Maybe we should start hiding math equations in IPv4 addresses since they use numbers.

Why bother? (4, Insightful)

fuzzyfuzzyfungus (1223518) | about 8 months ago | (#46355239)

Surely something as visible, and rife with opportunity for outrageous comedies of error, as DNS namespace collisions can simply be allowed to work itself out, through the time tested, enjoyable(for spectators), and reliable methods of endless risible fuckups followed by stilted non-denials from people who should have known better and vicious mockery from everybody else? Have we lost all sense of tradition? Taste? Humor?

(Perhaps more importantly: wouldn't it be neat if there were some sort of super cool, totally futuristic, security mechanism? One that used a secret number, that the server never told anyone, but still managed to prove that it knew, because number theory, instead of just relying on the URL being right? I bet that I'd have to go, like -25 years into the future to see a system that advanced...)

Re:Why bother? (0)

Anonymous Coward | about 8 months ago | (#46356255)

Heh heh. Reminds me of a former workplace, a department of the federal government. We had a... complex DNS setup (this was years ago) and sometimes things would act up a little. Usually not enough to bother regular users, but writing networked / Web based applications, I'd often notice it first. I'd call downstairs (that group was on the basement level, just like the IT Crowd) and they'd assure that everything was working fine. But in 5 minutes to half an hour, it would suddenly *actually* start working fine. They really were good folks, they were just pathologically unable to admit to anything being wrong.

Re:Why bother? (1)

bill_mcgonigle (4333) | about 8 months ago | (#46356731)

stilted non-denials from people who should have known better and vicious mockery from everybody else

Oh, you've had to speak with Exchange admins who can't figure out what HELO is too?

STOP (5, Insightful)

WaffleMonster (969671) | about 8 months ago | (#46355255)

The proliferation of TLDs has no positive effect on the Internet community whatsoever short of enriching ICANN and it's seedy network of bottom feeders.

Well ok say it helps scamming phishers and enables organizations to part with even larger sums of cash in any efforts to protect their brands.

Lighting up names with a loopback address like this "127.0.53.53" garbage is about the level of crap we can come to expect from the total idiots at ICANN. If you need to associate an A record pick an address guaranteed to be black holed not one that causes machines to resolve to thyself... extraordinarily moronic...

In my view DNS operators should take responsibility to prevent damage to their customers by not blindly delegating * to root zone operators. Only delegate known TLDs and require manual blessing of all operators before admitting any new TLDs.

Re:STOP (1)

dosius (230542) | about 8 months ago | (#46355323)

Like 0.0.0.0?

Re:STOP (2)

Z00L00K (682162) | about 8 months ago | (#46355415)

Or 255.255.255.255 - broadcast to the whole internet - get spammed by replies!

Re:STOP (1)

davidhoude (1868300) | about 8 months ago | (#46355427)

ICANN will probably release the TLD .0 soon.

Re:STOP (1)

MichaelSmith (789609) | about 8 months ago | (#46355453)

Then TLD . and we will be truly fucked.

Re:STOP (1)

Anonymous Coward | about 8 months ago | (#46355785)

...hammer time.

Re:STOP (4, Funny)

thogard (43403) | about 8 months ago | (#46355895)

I know a few people who have conspired to tell others that the nontraditional domains are like 1-900 phone numbers and when you use them, you will get a bill from your ISP.

Re:STOP (1)

mysidia (191772) | about 8 months ago | (#46355985)

In my view DNS operators should take responsibility to prevent damage to their customers by not blindly delegating * to root zone operators. Only delegate known TLDs and require manual blessing of all operators before admitting any new TLDs.

I agree.... ICANN was given their chance, and trust, AND they blew it.

Now a technical solution on the part of organizations administering DNS servers is warranted to head off this TLD foolishness.

Those wondering why 53.53 (4, Informative)

hcs_$reboot (1536101) | about 8 months ago | (#46355271)

53 is usually the port number from which DNS servers answer DN requests (usually UDP).

Re:Those wondering why 53.53 (3, Funny)

davidhoude (1868300) | about 8 months ago | (#46355429)

What about those of us just wondering Why?

Re:Those wondering why 53.53 (1, Informative)

Opportunist (166417) | about 8 months ago | (#46355965)

Money. Next question?

Re:Those wondering why 53.53 (-1)

Anonymous Coward | about 8 months ago | (#46355433)

Captain Obvious to the rescue!

Re:Those wondering why 53.53 (1)

jones_supa (887896) | about 8 months ago | (#46355495)

I figured out that one, but am still confused what's the purpose of that new special address in the first place?

Re:Those wondering why 53.53 (4, Informative)

hcs_$reboot (1536101) | about 8 months ago | (#46355693)

TFA is confusing. The way I understand it is adding a TLD like '.home' may have some wrongly configured systems resolve something.home from the newly 'home' zone made available from the Internet DNS, instead of a local/intranet resolution. In order to help sysadmins to catch inappropriate Internet resolution of such TLD (in case that FQDN doesn't exist, I guess since not in TFA) is to return the 127.0.53.53 address, a particular loop-back address that allows particular settings to be implemented in order to log/show the user that the intranet domain is currently not available., e.g. for a user connected outside the company (guess 2).

Re:Those wondering why 53.53 (1)

LoRdTAW (99712) | about 8 months ago | (#46356523)

"TFA is confusing"
Glad i'm not the only one, bear with me....

From what I can understand as a non-network-admin is that some private networks have their own suffix like .home and these can be mistakenly resolved for a public TLD since .home is now a valid TLD like .com. So if my home network is lordtaw.home and I have two systems: linux.lordtaw.home and windows.lordtaw.home, my router/DNS server can mistakenly try to resolve those domains to an external IP if it not configured correctly. And the fix if for external "public" DNS servers to return a specific loopback address which would hopefully show up in logs to alert me to the fact that my routers DNS server should know better than to try to publically resolve lordtaw.home over the internet. Correct?

When greed breaks stuff (2)

trifish (826353) | about 8 months ago | (#46355329)

All the people who warned them that they will cause permanent micro- and macro- disasters all over the world have been ignored. Due to greed. Let them be proud of their achievement.

Re:When greed breaks stuff (1)

hcs_$reboot (1536101) | about 8 months ago | (#46355731)

All the people who warned them that they will cause permanent micro- and macro- disasters

Many political figures have actually a "micro" view of events - i.e. the time difference [ NextElection - now ]. Not enough to accurately consider something as diluted in time as global warming.

Re:When greed breaks stuff (1)

Opportunist (166417) | about 8 months ago | (#46355961)

Think again: When (not if) the shit hits the fan, who do you think will get the blame? The C-level that fucked up and didn't even understand the problem or the admin who was never informed about it?

IPv6 should have been entrenched before TLD prolif (2)

unixisc (2429386) | about 8 months ago | (#46355385)

It was always known that IPv4 was running short, and given that, I blame ICANN for proliferating TLDs before IPv6 got well adapted, entrenched & established.

This is different from the question of whether there should be a gazillion TLDs worldwide (I disagree w/ the idea, but let's allow that for the sake of this discussion). Now, as it is, there are unlimited names and ways that websites can be formed, and to make things worse, TLDs are also mushrooming. So one needs an addressing scheme that could mathematically do the best job @ accommodating it.

The only Layer 3 protocol that I can think of that would achieve this is IPv6. Before that gets universally implemented and established, what was ICANN thinking laying out TLDs nilly willy? Result of that is more pressure on IPv4. Let's face it - IPv4 has hit its limit already. We had that discussion the other day of how it's not run out in North America, but once that happens this year, things will only get uglier: multiple levels of NAT would make it a de facto Layer 4 or above communication. The only way to preserve Layer 3 is IPv6, which seems to have enough for everybody.

Only good thing about this issue - if it forces the acceleration of adaption of IPv6 across the board - from infrastructure to last mile.

Re:IPv6 should have been entrenched before TLD pro (1)

MichaelSmith (789609) | about 8 months ago | (#46355449)

Having new TLDs beside .com should be better for the internet. Multiple name spaces should facilitate load sharing between DNS servers.

Re:IPv6 should have been entrenched before TLD pro (0)

Anonymous Coward | about 8 months ago | (#46355461)

There have always been plenty of TLDs, they just haven't been used. How's that going to change with new ones?

Re:IPv6 should have been entrenched before TLD pro (1)

unixisc (2429386) | about 8 months ago | (#46355463)

There are already several TLDs - one for each country. Having that, and in addition to that, .com, .net, .org, .gov and .edu was adequate. At any rate, this TLD proliferation shouldn't have been done before IPv6 was ubiquitous.

Re:IPv6 should have been entrenched before TLD pro (1)

KiloByte (825081) | about 8 months ago | (#46356053)

this TLD proliferation shouldn't have been done

Full stop. Your conditional clause is unnecessary and wrong here. As much as we need IPv6, the TLD diarrhoea should never have been allowed to happen.

Re:IPv6 should have been entrenched before TLD pro (0)

Anonymous Coward | about 8 months ago | (#46355543)

The parent comment has the same level of expertise I've come to expect from ICANN... too bad I cannot mod it -5 idiotic...

Re:IPv6 should have been entrenched before TLD pro (1)

mysidia (191772) | about 8 months ago | (#46355953)

Having new TLDs beside .com should be better for the internet. Multiple name spaces should facilitate load sharing between DNS servers.

No it won't. Everyone still needs a .COM. Alternate TLDs are a novelty market.

Re:IPv6 should have been entrenched before TLD pro (0)

Anonymous Coward | about 8 months ago | (#46355541)

Wut?

ICANN getting evil with TLDs has nothing to do with IPv6 proliferation...

Re:IPv6 should have been entrenched before TLD pro (1)

jon3k (691256) | about 8 months ago | (#46356405)

New TLDs shouldnt necessarily drive any real increase in IP address space usage. We've had vhosts for a long time.

Ipv4 served, but ipv6 ? (0)

Anonymous Coward | about 8 months ago | (#46355467)

Trapping TLD for Ipv4 would be fine, but what would be the equivalent for Ipv6 ?
Loopback is 127.0.0.0 /8, but there is only one place like ::1

So what trick would ICANN use for IPv6 ?

FMPOV, the proposal is only a trojan to have faster distributed censorship at the DNS level.

If the DNS setting of a corporation is lousy enough to let a request for .corp get out, let them eat their own shit and make the joy of the true .corp sites.
And who ever comes with the idea of private unofficial domain ending with .home, .corp or .mail should be flogged. It was the bad answer to a problem, time is now to pay for such bad work.

Fuck ICANN (-1)

Anonymous Coward | about 8 months ago | (#46355531)

I've been saying that ICANN needs to be disbanded since they started this whole TLD bullshit. Why isn't anyone listening?

Solution looking for a problem (1)

dutchwhizzman (817898) | about 8 months ago | (#46355561)

As if people haven't already made up domains and host names that didn't exist then and exist now? As if people hadn't been using public address space that wasn't assigned, but is now? Just because some "privately used" TLDs might get exposed because of sloppy system admins, ICANN shouldn't be running around in circles and cry and shout. Let it happen, it's happened before and it will happen again and again. Stop fighting the symptoms and let it ride out.

Re:Solution looking for a problem (1)

Opportunist (166417) | about 8 months ago | (#46355929)

I can see you're not responsible for security in a company.

I'm so NOT going to sit on an ejector seat just because some idiot thought it's fun to use some "internal" domain name for his projects without informing IT! And trust me, that shit will happen. And it's not going to be any sysadmins fault but rest assured that the PHB who fucked it up will twist it 'til the admin gets it.

I doubt there are too many around here who are looking forward to that.

127.4.0.4 (0)

Anonymous Coward | about 8 months ago | (#46355679)

Why not 127.4.0.4 instead of 127.0.53.54 .. if it's not actually found :)

Re:127.4.0.4 (1)

hcs_$reboot (1536101) | about 8 months ago | (#46355759)

...or 127.0.222.173, ie hex 7F00.DEAD.

is 10.0.0.0/8 really needed to be private? (1)

JavaBear (9872) | about 8 months ago | (#46355683)

Make it 10.0.0.0/12 for private networks, and reclaim the rest for public networks?

Re:is 10.0.0.0/8 really needed to be private? (1)

characterZer0 (138196) | about 8 months ago | (#46355715)

That does not address the issue they are trying to address here.

Also, there are so many people using addresses in 10.0.0.0/8 but not in 10.0.0.0/12 that you would have to give years lead time to let them get that changed. May as well go to IPv6.

Re:is 10.0.0.0/8 really needed to be private? (5, Informative)

squiggleslash (241428) | about 8 months ago | (#46355925)

This isn't the problem. As I understand it (and I've read the article multiple times and it's early in the morning so I may be getting it wrong), the problem is this:

1. ICANN is introducing new .TLDs (eg additions to .com, .net, .org) etc (we've known about this for a while, this isn't news.)
2. Common practice on private networks is to create and use an unused .TLD for the private network, for example ".internal", ".corp", etc. For example, your employer might, right now, be calling your workstation "pc117.nyoffice.intranet"
3. After analyzing global DNS hits, ICANN's researchers found that many/most of the new proposed .TLDs are already, apparently, in use by private entities for their private networks. You might ask how they know? Well, think in terms of a roaming laptop that upon connecting to a Wifi at Starbucks immediately, before the VPN is set up, tries to access "exchange-server.nyoffice.intranet". It makes the DNS lookup, and because the VPN isn't up yet, the DNS lookup goes to the global DNS servers, causing a bell to ring in ICANN's HQ (or something.)
4. ICANN needs to "do something" to alert people with private networks to change their TLDs, or else those people will, unintentionally, find themselves locked out of sites with the new TLD. (Cynical PoV: and this will decrease the value of the .TLDs themselves. Kerching!)

Now ICANN appears to believe that the best solution is to have the .TLDs return this odd 127.0.53.53 IP address instead of "domain not found" for all unknown domains, so that if a technie working for a company affected is roaming with their laptop, and they try to access "exchange-server.nyoffice.intranet" forgetting to put up the VPN, and ".intranet" is a new TLD, and they can't connect because the VPN isn't up, and they decide to check their Windows Event Logs to figure out why, then instead of "domain not found" which would immediately make them think "Oh wait, of course it can't be resolved, it's not a real domain and I'm not on the VPN", they'd see a weird IP address, and think "That's odd, let me Google that, there's obviously a problem with DNS."

(I think they'd have more luck if they made it a pair of real IP addresses, one A, one AAAA, pointing at a website that tells the roaming user the answer that they can report to a sysadmin, rather than forcing a sysadmin to Google something they may never become aware of because they may not roam in the first place, but to be honest, even that sounds like a bad idea, I'd rather IP addresses not be returned for invalid domains to begin with.)

Re:is 10.0.0.0/8 really needed to be private? (1)

JavaBear (9872) | about 8 months ago | (#46356903)

A very good explanation. Thanks.

Re:is 10.0.0.0/8 really needed to be private? (3, Interesting)

i.r.id10t (595143) | about 8 months ago | (#46357121)

So... what you are saying is that ICANN/IANA should've done something similar for names that has been done for the various "private" "non-routable" ip address pools (10.x.x.x, 192.168.x.x, etc) have done since The Beginning... there needed to be some TLD that would only work for local networks and queries.

Of course, since that didn't happen all those years ago admins and amatures (and amature admins even) have been using a random mess of things, usually done by trying to ping or get a nslookup for some hopefully imaginary TLD and when it works (or rather, returns a NXDOMAIN error) they assume they can use it locally without repurcussion.

Which means there are tens, hundreds, or maybe thousands (or more!) "fake" TLDs in use out there, some hard coded into applications that are no longer supported, etc. but are still in use. Which means to try and fix it now would be pretty much near impossible.

Re:is 10.0.0.0/8 really needed to be private? (1)

KiloByte (825081) | about 8 months ago | (#46356039)

Having more bits makes it easier to manage your local ranges. When you have multiple locations and a bunch of VPNs between them, more address space means you don't need to squeeze it tightly -- something that always backfires once there's a need for expansion.

127.0.53.53.... why not 127.0.42.42? (4, Funny)

Uzull (16705) | about 8 months ago | (#46355705)

>ping answer.to.the.ultimate.question.of.life.the.universe.and.everything
Pinging 127.0.42.42 with 32 bytes of data:
Reply from 127.0.42.42: bytes=32 time=2ms TTL=249
Reply from 127.0.42.42: bytes=32 time1ms TTL=249
Reply from 127.0.42.42: bytes=32 time=1ms TTL=249
Reply from 127.0.42.42: bytes=32 time1ms TTL=249

Ping statistics for 127.0.42.42:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
        Minimum = 0ms, Maximum = eternity, Average = ask Deep Thought

CANN I HAZ (0)

Anonymous Coward | about 8 months ago | (#46355783)

Your loopbakz?

Better yet, no new TLD (5, Insightful)

Anonymous Coward | about 8 months ago | (#46355801)

The best solution here is to simply stop this TLD madness because it provides no value at all. A new TLD can be created each time the UN recognizes a new country's existence, but for no other reason.

Re:Better yet, no new TLD (0)

Anonymous Coward | about 8 months ago | (#46356245)

The best solution here is to simply stop this TLD madness because it provides no value at all.

Why, it provides plenty of value. Oh, did you mean for people?

Well, it provides good value to ICANN, anyway.

Yay, applied spearfishing! (2)

Opportunist (166417) | about 8 months ago | (#46355919)

Let's face it, the whole craze around the new TLDs is a huge can of worms that serves no purpose (well, none but to make some people rich) while being a problem waiting to explode.

Take Mike, the manager. Mike is a good manager (yes, they exist. No, really!) and he's pretty competent. Well, not in IT, of course, but in his field. In IT, he has to rely on his IT department (and, as I said he is a good manager, he actually does). Mike takes his laptop home, not to play but to actually do some meaningful work. So he creates a rather sensitive document and decides to save it. Now, in our current world, the internal name "documents.thecompanyheworksfor" won't resolve and the system falls back onto his documents folder. Which is pretty neat, because that's what gets sync'd automatically the next time Mike drops his laptop into the docking station at work. No fuss for him and also none for his IT department.

In the new and improved world of TLDs at will, that server could well exist. And it does not necessarily belong to the company Mike works for.

And that's just the tip of the ice berg, how about launching some program from a remote location? Undocked, it won't launch, and if it's just a script that provides network information, who cares? In our new world, it may well launch some malware.

Now, of course one may say that IT should know that and IT should prevent it by ensuring that these things either resolve correctly or not at all. Fair enough. Now, who here can say that he knows of EVERY domain entry in his company's environment (provided you're not working for some mom'n'pop shop)? Who would put his job on the line for saying that there was never some self absorbed PHB who insisted in having the necessary rights to create what domains he thinks was funny without informing the IT department?

TLDs are going to be a security nightmare. But hey, who am I to complain, it's job security for decades!

Re:Yay, applied spearfishing! (1)

DarkOx (621550) | about 8 months ago | (#46356033)

Well that is pretty clearly a failure of the application documents.thecompanyheworksfor should be authenticated by the application in some fashion. An SSL certificate or similar. Otherwise it was always vulnerable to anyone who could manipulate DNS.

Whats more likely to happen is Mike opens up his laptop at home. The sync program starts up, and attempts a to resolve documents.thecompanyheworksfor, yesterday when it got back NXDOIN it immediately went back to sleep, got out of the way etc, concluding Mike was not on the corporate network. Today it gets back an address and hangs while it tries again and again to see if this server at 127.0.53.53 is going to respond.

HOST FILES (0)

Anonymous Coward | about 8 months ago | (#46355999)

This story is vaguely DNS related therefore HOST FILES.

cc: apk

Re:HOST FILES (0)

Anonymous Coward | about 8 months ago | (#46356093)

why dont u disproof apks mini fine points and logics u cowward trowel. apk buttsechezes ur mum. did apk defeateds u wit logics and sciences bcuz ur a ghey homo. use the host file.

~not apk

p.s. why dont u disproof apks mini fine points and logics u cowward trowel. apk buttsechezes ur mum. did apk defeateds u wit logics and sciences bcuz ur a ghey homo. use the host file.

and the winner is... (1)

fulldecent (598482) | about 8 months ago | (#46356815)

The entity that benefits most from bastardization of ICANN is... Google.

You can always find Google and Google can always find where you want to go. And now typing addresses into the address bar is about to get more painful.

I'm sorry (2)

tom229 (1640685) | about 8 months ago | (#46357113)

But if this happens on a corporate network, ever, your IT team is incompetent and needs to be replaced.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?