Stories
Slash Boxes
Comments

SoylentNews is people

posted by hubie on Thursday February 01, @12:23PM   Printer-friendly
from the Here-Here dept.

https://www.theregister.com/2024/01/29/icann_internal_tld/

The Internet Corporation for Assigned Names and Numbers (ICANN) has proposed creating a new top-level domain (TLD) and never allowing it to be delegated in the global domain name system (DNS) root.

The proposed TLD is .INTERNAL and, as the name implies, it's intended for internal use only. The idea is that .INTERNAL could take on the same role as the 192.168.x.x IPv4 bloc – available for internal use but never plumbed into DNS or other infrastructure that would enable it to be accessed from the open internet.

ICANN's Security and Stability Advisory Committee (SSAC) advised the development of such a TLD in 2020. It noted at the time that "many enterprises and device vendors make ad hoc use of TLDs that are not present in the root zone when they intend the name for private use only. This usage is uncoordinated and can cause harm to Internet users" – in part by forcing DNS servers to handle, and reject, queries for domains only used internally.

[...] ICANN's board still has to sign off the creation of .INTERNAL. But if you want to get ahead of the pack, there's nothing stopping you. Indeed, some outfits already use ad hoc TLDs. Open source Wi-Fi firmware project WRT has used .LAN, and networking vendor D-Link has employed .dlink.

There's nothing stopping you doing likewise.

But as ICANN's proposal for the idea noted: "Operators who choose to use private namespaces of the kind proposed in this document should understand the potential for that decision to have corresponding costs, and that those costs might well be avoided by choosing instead to use a sub-domain of their own publicly registered domain name."


Original Submission

This discussion was created by hubie (1068) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 5, Insightful) by Revek on Thursday February 01, @12:52PM (8 children)

    by Revek (5022) on Thursday February 01, @12:52PM (#1342627)

    Who cares what ICANN says about this. I use .local and wouldn't just change without some beneficial reason.

    --
    This page was generated by a Swarm of Roaming Elephants
    • (Score: 3, Funny) by Anonymous Coward on Thursday February 01, @01:02PM (1 child)

      by Anonymous Coward on Thursday February 01, @01:02PM (#1342628)

      Yeah, but this is internal, vs topical. You know you want a suppository from ICANN!

      • (Score: 2) by BsAtHome on Thursday February 01, @03:52PM

        by BsAtHome (889) on Thursday February 01, @03:52PM (#1342653)

        Only if you first liquefy the bits and then coagulate the bytes.

    • (Score: 0) by Anonymous Coward on Thursday February 01, @02:23PM

      by Anonymous Coward on Thursday February 01, @02:23PM (#1342630)

      I don't care either, but then I've been using .internal for a hellish long time now...longer than I care to think about.

    • (Score: 1) by Runaway1956 on Thursday February 01, @02:45PM (1 child)

      by Runaway1956 (2926) Subscriber Badge on Thursday February 01, @02:45PM (#1342637) Journal

      Reason: the default is almost always a poor choice from a security perspective. I won't recommend that you change to the new default, for the same reason. But, there have been articles in the past, where an attacker compromised the router, then used the few defaults in common use to get into the local network. Better to not use any default, old or new, instead, creating your own domain name. .smurf or .fbi or .button or .anydamnthingatall. There have been recent articles about well known routers having bugs in them, and we can be pretty sure that bad guys are poking around, trying to get inside the network with those bugs. When all else fails, security through obscurity can be quite useful.

      • (Score: 3, Interesting) by Opportunist on Thursday February 01, @02:52PM

        by Opportunist (5545) on Thursday February 01, @02:52PM (#1342642)

        I could see the benefit of using an "official" internal DNS name that gets hardcoded into DNS servers as MUST NOT BE ROUTED, akin to what RFC 1918 did for some IPv4 networks.

        It will still be quite interesting when you link two such networks together via VPN, but then, that has always been the staple of headaches for 1918 networks as well, so... Maybe solve that on the second level of "internal" DNS names? (like XXXX.office1.internal for the first, XXXX.office2.internal for the next one...).

    • (Score: 3, Touché) by Opportunist on Thursday February 01, @02:49PM

      by Opportunist (5545) on Thursday February 01, @02:49PM (#1342639)

      mDNS [wikipedia.org] (and the implications for various services that treat .local as something special) would maybe be one...

    • (Score: 3, Informative) by takyon on Thursday February 01, @10:07PM (1 child)

      by takyon (881) <takyonNO@SPAMsoylentnews.org> on Thursday February 01, @10:07PM (#1342708) Journal

      This takes .internal off the table forever, making it safer to use, and it could end up more widely used on home networks. Maybe not such a big deal but probably a better use of ICANN's time than whatever bad ideas are waiting in line behind this change.

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 1, Insightful) by Anonymous Coward on Friday February 02, @07:07AM

        by Anonymous Coward on Friday February 02, @07:07AM (#1342758)

        Took them a long while though. I proposed something like this to the IETF and the ICANN more than a decade ago.

        https://datatracker.ietf.org/doc/html/draft-yeoh-tldhere-01 [ietf.org]

        As wireless networking and devices become more common there may be a need
        for a convenient way to address hosts by physical location or context,
        especially when the users themselves are using mobile or wearable devices.

        A step towards this could be by reserving a special public use TLD (.here in
        the examples ). Then this TLD can be independently hosted at various
        locations, so that each resulting .here domain falls under the context of
        that particular location. For a similar concept see RFC1918 [RFC1918].

  • (Score: 4, Insightful) by WizardFusion on Thursday February 01, @02:06PM (12 children)

    by WizardFusion (498) on Thursday February 01, @02:06PM (#1342629) Journal

    They could have used a shorter name like .INT for example.

    .LAN, .HOME, .LOCAL could also have been proposed.

    • (Score: 4, Funny) by DannyB on Thursday February 01, @02:49PM (4 children)

      by DannyB (5839) Subscriber Badge on Thursday February 01, @02:49PM (#1342638) Journal

      They could have used a shorter name that has emoji characters.

      --
      To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
    • (Score: 0) by Anonymous Coward on Thursday February 01, @02:56PM (1 child)

      by Anonymous Coward on Thursday February 01, @02:56PM (#1342645)

      They could have also used .ANAL, that's LAN with an A.

      • (Score: 2) by VLM on Friday February 02, @12:53PM

        by VLM (445) on Friday February 02, @12:53PM (#1342775)

        Its "LAN A" read backwards because its for reverse DNS.

    • (Score: 3, Informative) by hendrikboom on Thursday February 01, @07:07PM

      by hendrikboom (1125) Subscriber Badge on Thursday February 01, @07:07PM (#1342680) Homepage Journal

      It seems that .local already has a meaning. https://en.wikipedia.org/wiki/.local [wikipedia.org]

      But how it differs from the proposed .internal escapes me.

    • (Score: 5, Touché) by zocalo on Thursday February 01, @09:41PM

      by zocalo (302) on Thursday February 01, @09:41PM (#1342703)
      You don't see it much, but .INT is one of the original gTLDs (actually created in the second RFC on the matter in 1988 at the request of NATO) from before money trumped sense and anyone with enough money could have their custom gTLD added to the root servers. I think the 150 or so - yes, it really is that few - international organisations that use .INT might be a bit upset if it suddenly gets used for something else.
      --
      UNIX? They're not even circumcised! Savages!
    • (Score: 2) by Unixnut on Thursday February 01, @10:01PM

      by Unixnut (5779) on Thursday February 01, @10:01PM (#1342707)

      I'd vote to use ".loc" for "local". Most TLDs are 3 characters or less, why would one that is reserved for internal machines (and therefore the one users will type the most often) be the longest?

    • (Score: 2) by theluggage on Friday February 02, @10:48AM

      by theluggage (1797) on Friday February 02, @10:48AM (#1342770)

      ….or all of those, maybe they could do a bit of research and find the top 5 currently in use as internal tlds - any of which would be dumb to use as public tlds.

    • (Score: 2) by VLM on Friday February 02, @12:55PM

      by VLM (445) on Friday February 02, @12:55PM (#1342776)

      TLD name should be .int_u32 for ipv4 and .int_u128 for ipv6 purposes.

      I can do DNS jokes all day long. They're like the "Dad Jokes" of IT work.

  • (Score: 5, Interesting) by crm114 on Thursday February 01, @03:52PM

    by crm114 (8238) Subscriber Badge on Thursday February 01, @03:52PM (#1342652)

    About the time Al Gore "Invented" the internet, our organization already had .com, .org, and .net registered. US$20 a year each.

    We decided to use .org for public, .net as private, .com for spam.

    Anything that left the perimeter with a ".net" or ".com" address, we knew and had full logs to remediate. And... surprise ... No "unexpected" data breaches.

    Long story, but our home network has a TLD that will never hit the interwebs.

    Seems like ICANN is striving to tell everyone they are still relevant, when IPv6 pretty much said "um... what do you do anyway?"

  • (Score: 2) by Whoever on Thursday February 01, @06:16PM (2 children)

    by Whoever (4524) on Thursday February 01, @06:16PM (#1342671) Journal

    Will the SSL gods allow ".internal" names to be added as an alternate name to signed SSL certificates?

    • (Score: 4, Interesting) by DannyB on Thursday February 01, @09:03PM (1 child)

      by DannyB (5839) Subscriber Badge on Thursday February 01, @09:03PM (#1342694) Journal

      Run your own internal certificate authority (CA). Generate your own CA cert. Use that to sign a cert for your .internal domain name. Make sure the CA's public cert is installed on all of your internal computers fleet wide.

      No browser outside of your organization is going to trust your SSL. All your internal browsers will.

      If everyone did this, then your internal browsers would not trust someone else's internal SSL.

      I spent only about ten seconds thinking through this approach. So it probably has some major flaw I have mist.

      --
      To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
      • (Score: 2) by DannyB on Thursday February 01, @11:28PM

        by DannyB (5839) Subscriber Badge on Thursday February 01, @11:28PM (#1342716) Journal

        If one of your organization's laptops is plugged in to someone else's network, and that network can resolve .internal domain names, your browsers wont trust the certificates of the servers there.

        --
        To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
  • (Score: 3, Interesting) by Rosco P. Coltrane on Thursday February 01, @09:17PM (1 child)

    by Rosco P. Coltrane (4757) on Thursday February 01, @09:17PM (#1342699)

    The point is nameservers is that some dude somewhere in the world can resolve the IP of another server somewhere else in the word. If this TLD is for unroutable addresses, who is the name resolution any good for? Surely local admins know how to setup their own nameserver for their own intranet.

    I guess ICANN has run out of things to sell...

  • (Score: 3, Interesting) by boltronics on Friday February 02, @03:49AM

    by boltronics (580) on Friday February 02, @03:49AM (#1342740) Homepage Journal

    My understanding is that .home.arpa is perfectly safe to use for internal domains, so that's what I use at home for hosts on my main LAN.

    https://en.wikipedia.org/wiki/.arpa#Residential_networking [wikipedia.org]

    The length of the domain doesn't matter at all here, as I have home.arpa to my host search path in /etc/resolv.conf (which is populated by the DHCP server).

    However, as the link states, it's meant for residential networks. It's likely fine as a default for many device vendors though, where home users are the target customers. An enterprise setup would be a different story… so there it makes more sense to just replace records like nas0.accounting.mycompany.com and httpd0.development.mycompany.com with nas0.accounting.mycompany.internal and httpd0.development.mycompany.internal or whatever, but it's hard to imagine this ever being a practical default.

    When it comes to internal domains for public facing hosts that I manage on my home network (on a separate DMZ VLAN), that's where I currently use a private subdomain of my publicly registered domain name, but I guess it would be easy enough to switch if this proposal becomes a standard.

    --
    It's GNU/Linux dammit!
  • (Score: 2) by VLM on Friday February 02, @12:51PM

    by VLM (445) on Friday February 02, @12:51PM (#1342774)

    I've had pretty good luck with RFC2606 / RFC6761 TLDs ".test" ".example" ".invalid" and ".localhost"

    This isn't a new idea, its merely adding a fifth TLD name to good old RFC2606

(1)