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

Comments

hacky

[dmitrygr]

Seems like a very hacky solution...

Re:hacky

[DrPBacon]

ICANT think of anything better.

Re:hacky

[Anonymous Coward]

ICANT think of anything better.

ICANN!

Re:hacky

[hcs_$reboot]

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

[fuzzyfuzzyfungus]

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

[Anonymous Coward]

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

[hcs_$reboot]

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

[DarkOx]

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

[DarkOx]

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

[Stalks]

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

Re:hacky

[skids]

Good summary. FWIW, People were using e.g. ".site" for local domain
for a long time. It was in the only draft RFC that addressed the issue,
and lacking any approved RFC people tend to follow the drafts. It was
noted on Wikipedia and many forums as to be used for this
purpose and along with some other TLDs had become a de-facto standard.
Then draft-ietf-dnsind-test-tlds-08 came along and removed it. Reserved
domains names continued to disappear from this draft document until they
were nearly all gone by the time RFC2606 was certified.

Then they started accepting and seriously considering applications for .site as a TLD and it looks like they are set to approve it. Boneheads.
So yes, in addition to unqualified names, there will be lots of problems with
software and configuration written when several TLDs were presumed safe.

RFC2606/RFC6761 have proper domains to use for test setups and documentation.
Unless/until they get suddenly ammended, which at this point, I wouldn't want
to wager on.

emergency response options

[Anonymous Coward]

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.

Why bother?

[fuzzyfuzzyfungus]

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

STOP

[WaffleMonster]

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

[thogard]

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.

Those wondering why 53.53

[hcs_$reboot]

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

Re:Those wondering why 53.53

[davidhoude]

What about those of us just wondering Why?

Re:Those wondering why 53.53

[hcs_$reboot]

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:Obsolete

[DarwinSurvivor]

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

127.0.53.53.... why not 127.0.42.42?

[Uzull]

>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

Better yet, no new TLD

[Anonymous Coward]

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:is 10.0.0.0/8 really needed to be private?

[squiggleslash]

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?

[i.r.id10t]

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.