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.
search mydomain.com
nameserver 127.0.0.1
There, problem solved.
No need to say thank you...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
forcibly de-delegate google.com immediately. Its existence is offensive.
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.
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.
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...
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.
Having new TLDs beside .com should be better for the internet. Multiple name spaces should facilitate load sharing between DNS servers.
http://michaelsmith.id.au
There have always been plenty of TLDs, they just haven't been used. How's that going to change with new ones?
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.
Trapping TLD for Ipv4 would be fine, but what would be the equivalent for Ipv6 ? /8, but there is only one place like ::1
Loopback is 127.0.0.0
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. .home, .corp or .mail should be flogged. It was the bad answer to a problem, time is now to pay for such bad work.
And who ever comes with the idea of private unofficial domain ending with
Wut?
ICANN getting evil with TLDs has nothing to do with IPv6 proliferation...
The parent comment has the same level of expertise I've come to expect from ICANN... too bad I cannot mod it -5 idiotic...
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.
I was promised a flying car. Where is my flying car?
Why not 127.4.0.4 instead of 127.0.53.54 .. if it's not actually found :)
Make it 10.0.0.0/12 for private networks, and reclaim the rest for public networks?
>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
Your loopbakz?
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.
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.
This story is vaguely DNS related therefore HOST FILES.
cc: apk
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.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
New TLDs shouldnt necessarily drive any real increase in IP address space usage. We've had vhosts for a long time.
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 was raised on the command line, bitch
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.
Everyone still needs a .COM.
Why? Typing in domain names is as obsolete as AOL keywords.
Now the MSCE folks are getting annoyed that people even more remote from certified professional engineers are taking up the label. Face it - help desk monkeys that couldn't finish high school and did no self study, training or experience get that title the minute they pick up a script to read over the phone.
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.
I wonder if this 127.0.53.53 would preempt the ISP's DNS redirector (gives end-user customized web pages for unknown or unresolvable TLD).
If so, then I'm all for it.
I can see it now - some jackass will create a trojan that lives on 127.0.53.53:53 and burn a lot cycles and machines!
For all of the small devices out there - they will now need some sort of hack to listen to localhost...just to reply to the DNS request. How big will this stupid daemon/program have to be? Then will come the "hacks" to fix the case where the machine has in its own cache the address...but the DNS server does not.
What happens to networking? Do you now have to subnet out 127.0.0.0/8 to something different? I can already see the case where some "large group" wants a "common" hack...a 127.0.53.53:53 server hosted off one box serving a bunch of others...and 127.0.0.0 will forever be destroyed!
I have a big enough problem with my stupid browser deciding that when I type "blahblah" into the host bar that if it can't reach "http://blahblah:80/" that it should automatically default to "http://blahblah.com/" or google "blahblah" ... yeah, that's what I need, the internal hostnames leaked to google, thanks idiot browser developer.
Okay, it's good for grandma and everyone else using browsers. There should be a clear UI element that appears when this happens to allow me to disable it.
Isn't that more on Unix-like web servers? I doubt that any IIS based servers implement virtual hosts, or do they?
What are these 1400 new top level for? sounds like a real bad idea.
Chances are that they may still have antiquated routers/networks hard coded to 19.0.0.0/8, and would have to spend a considerable amount to replace. In the meantime, having that entire Class A means that internally, within the organization, they can assign them to their various locations worldwide, w/o batting an eyelid or bothering ARIN.
Like I've argued, nobody should ever return any IPv4 addresses: even if they've switched completely to IPv6, they would likely still need dual stacked support for communicating w/ those that don't have IPv6 support, and it's silly to go over to IPv4+NAT if they already have private IPv4 addresses. Also, even w/ NAT, one can't reduce their public IP addresses to 1. Since the most common NAT used is Port Address Translation, or PAT (overloading), where multiple public IP addresses help alleviate network traffic, that too would not relieve much pressure on IPv4.
Bottom line - just focus on adding IPv6 support and continual improvement in its services & performance, and go fully dual stacked. Over time, the need for IPv4 should then go away
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.
Just do a loopback 127.0.0.1 local website ;p Bam done! Or even better 0.0.0.0
I wish ICANN would finally give us some real "reserved" internal TLDs, but we do have a few we can work with:
RFC 2606 https://tools.ietf.org/html/rf...
test, example, invalid, localhost
"gTLD Applicant Guidebook", Section 2.2.1.2.1 "Reserved Names" http://newgtlds.icann.org/en/a...
afrinic, iana-servers, nro, alac, icann,
rfc-editor, apnic, iesg, ripe, arin, ietf,
root-servers, aso, internic, rssac, ccnso,
invalid, ssac, example*, irtf, test*, gac,
istf, tld, gnso, lacnic, whois, gtld-servers,
local, www, iab, localhost, iana, nic
Most of those aren't really suitable for internal network names except perhaps "tld" and "local" but we can't use "local" because of multicast dns... but that RFC does reference some other names we're PROBABLY safe to use:
RFC 6762 http://tools.ietf.org/html/rfc...
intranet, internal, private, corp, home, lan
It'd be great if we could just get the alternate example domains from RFC 6762 explicitly reserved.
Sure they do - all the major web servers and hosting platforms can use and define vhosts (it's just that the mechanism for creating them differs on each platform). IIS for example, if you create a new site, using "All IP Addresses" port 80, will require that you designate a host header so that the HTTP engine can route the request to the right Web Site (and corresponding content). All IP Addresses port 80 with an empty Host Header acts as a "catch-all" and is assigned to the Default Web Site. Which you generally disable, and create your own config for, if you know what you're doing. Apache, on the other hand, configures those vhosts in text files (nowadays under sites-enabled, as I recall). But the functionality is all there on pretty much all major platforms.
Now if you're arguing that the administrators of IIS servers are exponentially less likely to have a clue about host headers, when compared to their Apache/nginx counterparts - well then from my experience you're absolutely right (my history is MS consulting, and the number of IIS admins who want 20 IP addresses for 20 sites because they don't get how to do host headers, DNS resolution etc, cannot be counted - the reverse can be counted on both hands over 20 years of doing this stuff).
people will use .com and the Countrycodes anyway. The rest will just be reserved or redirections.
...The IP addressing and the naming (DNS) are two different structure.... One is physical and the other logical....
For ever smaller values of logical.
Yes, you would use host headers in IIS.