Slashdot Mirror
ICANN Considers Using '127.0.53.53' To Tackle DNS Namespace Collisions
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."
Seems like a very hacky solution...
-------
1. Enjoy your job
2. Make lots of money
3. Work within the law
Choose any two.
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.
I'm using MSDOS, you insensitive clod!
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...)
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.
53 is usually the port number from which DNS servers answer DN requests (usually UDP).
Slashdot, fix the reply notifications... You won't get away with it...
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.
Maybe we deserve this world ?
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.
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.
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).
wattcp has been around for ages. Like, seriously, where have you been?
http://www.vogons.org/viewtopi...
He clearly needs to reconfigure his extended memory.
>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
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.
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!
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.) .TLD for the private network, for example ".internal", ".corp", etc. For example, your employer might, right now, be calling your workstation "pc117.nyoffice.intranet" .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.) .TLDs themselves. Kerching!)
2. Common practice on private networks is to create and use an unused
3. After analyzing global DNS hits, ICANN's researchers found that many/most of the new proposed
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
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.)
You are not alone. This is not normal. None of this is normal.
Maybe we should start hiding math equations in IPv4 addresses since they use numbers.
But if this happens on a corporate network, ever, your IT team is incompetent and needs to be replaced.
If it ain't broke, don't fix it.
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.
Don't blame me, I voted for Kodos
Back when I used to work for Boeing, our internal TLD was .com. Anything looking for a .boeing .com domain would be resolved via our internal DNS system. All other .com (and any other TLDs) were forwarded to the public DNS services through a firewall.
Were someone to take their laptop out of the company, .boeing.com requests would be resolved via their external DNS service. And they could deal with erroneous requests for internal services in a number of ways. Deny then, or divert them to some sort of error handling service (web page: "Aren't you supposed to be at work right now?") Hand them over to some sort of VPN login service or other firewall portal. Or obfuscate the response, keeping people outside from probing around and guessing at the internal company network structure.
It all worked and it handled everything secure within the companies systems.
Have gnu, will travel.
By being an ISP and insisting that new residential Internet customers configure their modem through an EXE. This EXE ends up installing "ComWarner Connection Agent" that listens on localhost:80 and serves up 302 redirections to whatever shite-finder service paid ComWarner for ads.