Please create an account to participate in the Slashdot moderation system


Forgot your password?
The Internet

ICANN Considers Using '' To Tackle DNS Namespace Collisions 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 as an IP address in the hopes that sysadmins will flag and Google it."
This discussion has been archived. No new comments can be posted.

ICANN Considers Using '' To Tackle DNS Namespace Collisions

Comments Filter:
  • by hcs_$reboot ( 1536101 ) on Thursday February 27, 2014 @04:48AM (#46355271)
    53 is usually the port number from which DNS servers answer DN requests (usually UDP).
  • Re:Obsolete (Score:4, Informative)

    by DarwinSurvivor ( 1752106 ) on Thursday February 27, 2014 @05:29AM (#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 ( 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).

  • by hcs_$reboot ( 1536101 ) on Thursday February 27, 2014 @07:10AM (#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 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).
  • by squiggleslash ( 241428 ) on Thursday February 27, 2014 @08:26AM (#46355925) Homepage Journal

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

  • by Opportunist ( 166417 ) on Thursday February 27, 2014 @08:39AM (#46355965)

    Money. Next question?

  • Re:hacky (Score:4, Informative)

    by skids ( 119237 ) on Thursday February 27, 2014 @11:35AM (#46357583) Homepage

    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.

"Well, it don't make the sun shine, but at least it don't deepen the shit." -- Straiter Empy, in _Riddley_Walker_ by Russell Hoban