back to article ICANN reserves .internal for private use at the DNS level

The Internet Corporation for Assigned Names and Numbers (ICANN) has agreed to reserve the .internal top-level domain so it can become the equivalent to using the 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 IPv4 address blocks for internal networks. Those blocks are reserved for private use by the Internet Assigned Numbers …

  1. Khaptain Silver badge

    Would have prefered "*.int"

    I would have preferred a shortened version, a la ".int" rather than ".internal".

    1. may_i Bronze badge

      Re: Would have prefered "*.int"

      Or maybe "*.lan", which is what I already use on my local area network.

      1. MatthewSt Silver badge

        Re: Would have prefered "*.int"

        No harm in having more than one

        Can they add .local while they're at it?

        1. Anonymous Coward Silver badge
          Boffin

          Re: Would have prefered "*.int"

          .local used to be the defacto standard, but bonjour/multicast stuff adopted it and buggered it up for normal use.

          1. Kurgan

            Re: Would have prefered "*.int"

            Yes, there was indeed .local, but then some smart ass stole it from us.

          2. david 12 Silver badge

            Re: Would have prefered "*.int"

            adopted it and buggered it up for normal use.

            Last laugh was on them, which is perhaps one reason why .internal has been adopted.

            By design, bunjour/multicast captured .local and prevented it's historic/customary use. But in practice, people who aren't Apple eventually built in work-arounds so multicast could be used in conjunction with .local domains. No doubt an irritating complexity, with concomitant error and security implications

        2. DanAU

          Re: Would have prefered "*.int"

          .local is used by mDNS. You should never use .local domains with regular DNS.

          1. PC Paul

            Re: Would have prefered "*.int"

            That's the point. .local was in use widely by many organisations well before they decided to use it for mDNS/Bonjour.

      2. heyrick Silver badge

        Re: Would have prefered "*.int"

        I think my router uses .home as a suffix for internal things. As mentioned below, there's also .local but that works differently.

        1. DanAU

          Re: Would have prefered "*.int"

          The manufacturer really should have used .home.arpa as it was reserved for this purpose. The risk of using something like .home was that ICANN may make a real .home TLD one day.

      3. Tom 38

        Re: Would have prefered "*.int"

        .lan and .local both imply a short distance - which is probably the most common use of private network ranges, but its definitely not the only one. I use private network ranges that span the globe - they are not local, but they are internal.

      4. Darkk

        Re: Would have prefered "*.int"

        I prefer the *.lan as well to go with the usual three letter naming convention like .com and .net. I've been using that for years for internal use without issues.

    2. katrinab Silver badge
      Boffin

      Re: Would have prefered "*.int"

      .int is already reserved for international treaty organisations, for example www.un.int or nato.int

      1. Lee D Silver badge

        Re: Would have prefered "*.int"

        Yep.

        My current workplace uses .internal.

        My previous workplace used <companyname>.int

        They can never own that domain, and it generates all kinds of lookups to external DNS for everything you do.

        Also means you have to workaround it every time you have anything sync into the cloud, where you have to do string replacement with their real external domain, and so on.

        I can't imagine that anyone using .internal is actually calling out to the rootservers much to resolve it because it's simply not a valid TLD.

        But .int has been in active use since 1988 (yes, honestly!), and has extremely restrictive membership requirements, so that was always a dumb one to use. There are probably thousands of such places looking up .int all day long just because it's inherent in their AD domain, etc. and they haven't bothered to cache/filter it explicitly.

        1. R Soul Silver badge

          .internal and the root servers

          I can't imagine that anyone using .internal is actually calling out to the rootservers much to resolve it because it's simply not a valid TLD.

          Try again. All sorts of bogus domain names from supposedly "private" networks leak in huge numbers of queries to the One True Root.

          There have been many studies on this. In the one ICANN commissioned ~10 years ago, the root servers got more queries for .internal domain names than for any ccTLD or gTLD (apart from .arpa, .com, .net and .org). See https://forums.theregister.com/post/reply/4909322 for more details.

          Resolvers have no way of knowing what is and isn't a valid TLD unless they query the One True Root or hold an up to date copy or the root zone.

          Unless resolving servers get specially configured to handle .internal (say) on some private net, DNS lookups for that net's .internal domain names will leak to the One True Root.

          1. Claptrap314 Silver badge

            Re: .internal and the root servers

            Help me out, but isn't that kind of the point of this decision? Since .internal is forever banned from the public internet, no DNS server ever needs to go to the internet to resolve it. Sure, this won't kill the traffic today, but I bet it makes a big different at the root level very quickly--because EVERY major caching server on the public internet will NXDOMAIN those rather than attempting a lookup. They will do it because it speeds up their response time.

            1. R Soul Silver badge

              Re: .internal and the root servers

              You're badly confused. .internal isn't banned from the public Internet. And even if it was, there's no DNS police to enforce that ban and throw the offenders in jail.

              All ICANN has done here is say .internal can be safely used on private nets because they're never going to delegate that TLD. [For some definition of safely.] That doesn't stop anyone from using .internal anywhere or letting that bit of the name space pollute the public DNS. Just like they could before ICANN's latest proclamation.

              Next, DNS servers will go to the Internet to resolve .internal domain names. Unless they're specially configured not to. Too many bozos don't realise that. I've lost count of the number of times I've had to tell corporates that lookups for secret-project-name.internal leaked from their "secure" intranet. And their lack of DNS clue caused that.

              Having every major caching server return cached NXDOMAINs for lookups of .internal names makes little difference in the overall scheme of things. These servers will have supported negative caching for about 25 years or so. [RFC2308 was published in 1998.] Which means .internal lookups from resolvers in the big eyeball nets have had marginal impact on root server traffic for those names since the days when AOL was carpet-bombing the planet with their CDs.

              However these major caching servers are not - and never have been - responsible for the overwhelming majority of the .internal DNS lookups that hit the root. Those tend to come from idiot forwarders or misconfigured stub resolvers that go nowhere near a decent resolving server. That ~15yo ICANN study showed that the root was getting more lookups for .internal than just about every ccTLD and gTLD. It's unlikely that pattern of bad behaviour has changed much since then, even if the all-fours are now slurping up the bulk of resolver traffic.

    3. Chris Hills

      Re: Would have prefered "*.int"

      .int has historically already been used, e.g. by tpc.int

    4. This post has been deleted by its author

    5. david 12 Silver badge

      Re: Would have prefered "*.int"

      I would have preferred a shortened version, a la ".int" rather than ".internal".

      You're lucky. It might have been .localdomain

      In the icann study, .internal was only one place more popular than .localdomain

      Still handily beaten by .local, but far more popular than .home or .lan

      Not surprised to see .wpad -- that's a horrible broken protocol that never works.

      The one I don't recognize is ".olk". Is that used somewhere in Exchange? Or in some non-english language?

      1. heyrick Silver badge

        Re: Would have prefered "*.int"

        "The one I don't recognize is ".olk"."

        As a file extension, it's something to do with Outlook. Can't think why it would be looked up unless Microsoft is running some sort of special backend for their cloudy stuff, or something is horribly broken and is trying to resolve filenames?

      2. that one in the corner Silver badge

        Re: Would have prefered "*.int"

        > You're lucky. It might have been .localdomain

        The draft for RFC 2606 did listed .localdomain - it also recommended that .local, .domain, .lan, .home, .host and .corp where all given the same treatment, meaning we could have been using any of those safely since 1999 - if only those recommendations had lived on into the released RFC 2606.

        But that would have lost ICANN a quarter century of laughing at us trying to set up LANs that weren't going to suddenly go ga-ga.

    6. DanAU

      Re: Would have prefered "*.int"

      The .int TLD has existed for 35 years, so it can't be used for this. https://en.m.wikipedia.org/wiki/.int

    7. Michael Wojcik Silver badge

      Re: Would have prefered "*.int"

      Not .void?

      Or .static, to indicate internal linkage...

      1. Anonymous Coward
        Anonymous Coward

        Re: Would have prefered "*.int"

        > Not .void?

        If you resolve long enough into .void, the .void will resolve back into you.

  2. Pascal Monett Silver badge

    "it is not certain setting aside .internal will improve anything"

    Maybe it won't, but given that it is, apparently, already widely used, might as well recognize it.

    That said, apparently companies can create internal domains as they wish, so ICANN doesn't really have any say over that.

    1. stiine Silver badge

      Re: "it is not certain setting aside .internal will improve anything"

      You can also use any ipv4 addresses that you wish. Just be ready for the well-deserved hatred when this becomes known.

      bonjour fucked up .local

      .int is already an actual TLD.

      There's nothing to prevent you from using any domain or network you want on your internal networks...provided that you never need to reach hosts on that domain or network.

      When I migrated from CentOS 6, I changed our internal domain from .local to .internal because of the behavior of bonjour. I considered changing to .fuck or .dotdot but decided that doing so would get me fired...

      1. Claptrap314 Silver badge
        Pint

        Re: "it is not certain setting aside .internal will improve anything"

        "What's the dns name of our company docs server?" "doc-dot-dot-dot".

        Evil laughter from here all evening. Have one, repeatedly ------------------>

        1. Anonymous Coward
          Anonymous Coward

          Re: "it is not certain setting aside .internal will improve anything"

          When the new plague of new TLDs became available, I briefly considered trying to register cloud.cloud. My email address would have been cloud@cloud.cloud.

          Then I sobered up.

          An old colleague of mine used to have a test lab with servers called up, down, off and on.

          1. Anonymous Coward
            Anonymous Coward

            Re: "it is not certain setting aside .internal will improve anything"

            In the lab there used to be a pair of systems named "top" and "bottom".

            I occasionally considered re-racking them to be the other way 'round.

            1. Anonymous Coward
              Anonymous Coward

              Re: "it is not certain setting aside .internal will improve anything"

              >> In the lab there used to be a pair of systems named "top" and "bottom".

              > In the lab there used to be a pair of systems named "top" and "bottom"

              Ok, so who has systems named "strange" and "charm'?

        2. NohSpam

          Re: "it is not certain setting aside .internal will improve anything"

          I think I'm going to change my LAN domain to dot ellipsis

          So, .…

    2. Diogenes8080

      Re: "it is not certain setting aside .internal will improve anything"

      It prevents any number of Onanists from registering it as a spurious public top-level domain with a compliant ICANN in order to extort money from those who already use it.

      I assume that the usual suspects tried it on but ended up on an oompa-loompa hit squad. "It's not chocolate in that glass pipe!"

    3. Jamie Jones Silver badge

      Re: "it is not certain setting aside .internal will improve anything"

      At least now DNS software providers can legitimately place it in the "black hole" default configs, it should reduce a lot of needless root DNS traffic.

    4. DS999 Silver badge

      Re: "it is not certain setting aside .internal will improve anything"

      apparently companies can create internal domains as they wish, so ICANN doesn't really have any say over that

      The goal wasn't to try to get everyone to create internal domains in their company as .internal, but for third party OEMs who build stuff into devices like wireless routers to standardize. When a company creates its own internal domain they presumably have an IT staff that made that happen and manages it, so they will have DNS servers appropriately configured that they don't let lookups on that domain escape onto the internet and bog down root DNS servers.

      But if you have companies like Dlink creating their own in consumer facing devices, you might see e.g. a "power user" at home creating a Powershell script that uses .dlink, then they replace their Dlink with a Linksys and that forgotten Powershell script they left running every hour is now sending lookups for ".dlink" to the Linksys which dutifully sends it upstream to the ISP's DNS server, which failing to find it sends it to a root server for an authoritative lookup.

      I suppose it isn't a big issue, since DNS servers do negative caching so there shouldn't be a torrent of .dlink lookups even if every Windows user had such a Powershell script on their PC. But imagine if a company used something more generic, like ".router", and then someone purchased that TLD. Such a TLD would be of little use if everyone using a certain brand of wireless router wasn't able to reach their website.

      1. Anonymous Coward
        Anonymous Coward

        Re: "it is not certain setting aside .internal will improve anything"

        I'd say that was the same as buying the 1.1.1.0/24 network, as someone did, and putting a sniffer on it, which they did.

        They then published stats on the number of routers, switches, and other misconfigured devices. As it turns out, you can have the IQ of a sandwich and still be a well-paid, professional Cisco network admin.

        1. A.P. Veening Silver badge

          Re: "it is not certain setting aside .internal will improve anything"

          As it turns out, you can have the IQ of a sandwich and still be a well-paid, professional Cisco network admin.

          Please don't insult sandwiches.

    5. Anonymous Coward
      Anonymous Coward

      Re: "it is not certain setting aside .internal will improve anything"

      I have just always used a subdomain of the registered domain. I pick a 3 letter prefix for the server names based on the company name, then use that with a numerical suffix in the unlikely event I ever have more than one domain in a forest.

      So if I pick XYZ to be the server name prefix, the internal namespace is xyz01.mydomain.com.

      Never had a problem with this approach.

      1. Claptrap314 Silver badge
        Mushroom

        Re: "it is not certain setting aside .internal will improve anything"

        You've only dealt with a limited number of VPs, then....

  3. Anonymous Coward
    Anonymous Coward

    Good!

    My home router's an AVM Fritz!Box, which hardwires fritz.box as the LAN domain. Earlier this year, some miscreant registered that domain, meaning that they'd see traffic resulting from lookups on 1.1.1.1, 8.8.8.8 etc., or, indeed anything other than the router itself. (This happens a lot, usually as a consequence of measures to prevent one's ISP from seeing what you're looking up, or simply not using the router's LAN.) Whoever it was didn't get around to putting up fake router login pages, but they could have; maybe they were just interested in capturing internal addresses and names.

    AVM seemed to gain control of the domain after a couple of months, and, in response to an enhancement request I raised, said it would give serious consideration to allowing the default LAN domain to be changed. .internal, here I come!

    1. tekHedd

      DoH

      Another reason a dedicated .internal TLD is not just useful but necessary is that you can no longer use .madeuptld and be even hopeful that lookups will be directed to your internal DNS server, thanks to DoH.

    2. Anonymous Coward
      Anonymous Coward

      Re: Good!

      AVM now have a page up on the intertubes at fritz.box that basically says, in German, that you're not where you want to be and gives you some tips on how to find your router's login page. So on my LAN fritz.box resolves to my router, and anywhere else it doesn't result in a root level DNS query. Seems a sensible arrangement as of today.

  4. BristolBachelor Gold badge

    Worked in a few (related) places that all used .CORP a the internal TLD. But ICANN already sold that one.

    1. Frank Zuiderduin

      Not really: https://en.wikipedia.org/wiki/.corp

    2. Anonymous Coward
      Anonymous Coward

      It didn't. ICANN decided nobody could get .corp (and .home) because too many fuckwits were already using these TLDs on their supposedly private networks.

      1. Arthur the cat Silver badge

        .corpse should probably be reserved for goths.

      2. that one in the corner Silver badge

        > ICANN decided nobody could get .corp (and .home) because too many fuckwits were already using these TLDs on their supposedly private networks.

        Well, those were listed in the draft RFC 2606 so perhaps those "fuckwits" were just following what they believed was going to become Standard Practice.

        And if their use of those tld's *has* really, truly, meant that ICANN will never release them, then - that is a Good Thing.

        Unless, of course, you were hoping to buy .home and hold everyone to ransom, back in the long-distant past of up to last month when ICANN had refused to actually guarantee us a sensible and *well publicised*[1] tld to use

        [1] before you leap in with .home.arpa or similar that were also unofficial all these years but unlikely to be sold.

  5. Zippy´s Sausage Factory

    Actually a nice decision. Going to start using .internal at home I think.

    1. Bebu
      Windows

      start using .internal at home I think.

      I was pretty sure the Stasi weren't likely to be back in business so I purloined the .DD tld. ;)

      The DDR collapsed before the internet was enough of a thing in Stasiland for the .DD to be registered but I notice .SO is still in use, perhaps repurposed for "special operation." :(

      As long as your resolvers and internal nameservers don't pester the root servers or other external name servers with your own networking delusions you can do whatever you like even purloin X.com or sub-domains thereof.

      Might even be worth having space-karen.x.com, ketamine.x.com, etc etc locally just for your crappy or otherwise dodgy hardware.

      X.com could actually mean "was a commercial entity but now defunct" which might be well be prophetic (if self fulfilling.)

  6. K

    Better late than never..

    But probably 15-20 years too late - Split horizon resolution is all the range these days.

    1. J. Cook Silver badge
      Go

      Re: Better late than never..

      Yup. been doing it with the few systems we still have on-prem at [RedactedCo], if only to make Internal vs. external DNS resolution product a consistent UX.

      I'm still mildly cheesed off that ICANN didn't reserve out .local as a TLD, because for a while Microsoft was suggesting that as a 'best practice' for Active Directory domains that would never see any form of public internet. (which makes for a hellua fun time when reconfiguring a forest that's been around since AD was first rolled out for talking to AzureAD.)

    2. Anonymous Coward
      Anonymous Coward

      Re: Better late than never..

      Where I work, split horizon DNS is mostly gone now that the network is almost entirely IPv6-only, since the systems can use the same IP for internal and external. Only some of the edge nodes that customers can directly connect to have IPv4 addresses. Stats are somewhat inline with Google's - a bit over 50% of all customer traffic in the USA is over IPv6, and ~40% worldwide.

    3. Anonymous Coward
      Anonymous Coward

      Re: Better late than never..

      > But probably 15-20 years too late - Split horizon resolution is all the range these days.

      Because we all know that the majority of LANs in the world are connected and controlled by Routers and SysOps who know what the bleep "Split Horizon Resolution" *is* and have set it up properly.

      NOT.

      You have twigged that there are far more literal home LANs than there are company? And that the vast bulk of company LANs are not corporate?

  7. mmccul

    Is it really final?

    A little unfortunate that no links were provided to ICANN of the actual results. The only thing I was able to find myself was a note that the comment period was closed and that the recommendation would be forwarded to the ICANN board for further consideration, which would imply it isn't final.

    Or is there another link that's a little harder to find?

    1. stiine Silver badge
      Coat

      Re: Is it really final?

      ICANN find it either.

    2. diodesign (Written by Reg staff) Silver badge

      Re: Is it really final?

      Yeah - we've added a link now.

      C.

    3. ssharwood

      Re: Is it really final?

      Sorry bout that folks - board docs here with the decision and links to consultations. https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-special-meeting-of-the-icann-board-29-07-2024-en#section2.a

  8. forcage

    At last

    "You can just create a subdomain of your existing domain name" - The problem was the assumption that people have "existing" public domain names. I have a home server, network printer, notebooks, etc but no public domain name. That would be a costly subscription that may expire or otherwise become lost among the providers.

  9. train_wreck

    Hmmm, i’ve been using .LAN for all my personal servers/devices. Always thought it was a relatively safe choice.

    1. Claptrap314 Silver badge

      NOTHING is safe with ICANN. Just ask Amazon...

  10. jeremya
    Stop

    But will it break things?

    There is an existing problem with non-standard but still valid DNS names.

    Some software, especially to do with network functions on windows systems, but not necessarily Microsoft code, breaks when you use DNS suffixes that aren't in the traditional DNS hierarchy.

    A whole bunch of the new TLDs get rejected by email address validators. More importantly, many 'wizards' break because if they don't see TLDS as defined 20+ years ago. I think (from memory) the sharepoint and exchange wizards have these problems. There are many more examples.

    I'm interested in how .internal will be resolved. will your local DNS server recognise it and not recurse up the DNS tree? And/or is there a mechanism to return some code on a DNS query that says this is a non-public name?

    1. Richard 12 Silver badge

      Re: But will it break things?

      Defining it causes it to become so.

      The root nameservers can mark it as not existing for the next 68 years, and that quickly propagates outward via the normal methods.

      So your ISP DNS probably already immediately returns 'nope', and thus your router will probably only ever send one request per boot to the ISP.

    2. Anonymous Coward
      Anonymous Coward

      Re: But will it break things?

      "Some software ... breaks when you use DNS suffixes that aren't in the traditional DNS hierarchy."

      So don't fucking do that. Duh!

    3. Anonymous Coward
      Anonymous Coward

      Re: But will it break things?

      Getting SSL certificate for non public facing internet domain names is tricky as well. Came across this when trying to get a SAN certificate. The primary name was internet facing, but I wanted to add the internal server hostname as well. The client had originally had an SBS server so was using .local for the internal namespace.

      Cert vendor wouldn't issue it until I took the internal name off.

  11. EricB123 Silver badge

    Who Knew?

    Cloud Infrastructure Month?

  12. computing

    I am suspicious of ICANN after the fiasco that was the aborted sale of ".org". Back then ICANN stood by and pretended nothing was amiss as preparations were made to sell gTLD to private-equity company Ethos Capital. See https://www.theregister.com/2020/01/21/org_sale_fiasco/. So now, when ICANN *doing* anything substantial, you've got to consider if there is a hidden agenda.

    So ICANN has reserved '.internal' for internal use. That's great. But they'd *rejected* a bunch of other gTLDs years earlier -- '.corp', '.home', and '.mail'. The reason was the same as it is now -- people use them internally. See https://en.wikipedia.org/wiki/.corp

    So does reserving '.internal' now mean '.corp', '.home', and '.mail' gTLDs may be up for sale in future?

    1. R Soul Silver badge

      So does reserving '.internal' now mean '.corp', '.home', and '.mail' gTLDs may be up for sale in future?

      In theory, maybe. In reality, never.

      ICANN's put .corp, .mail and .home on some super-special list of TLDs that cannot be created. They were put on that list for security and stability reasons. They will never come off that list until those security and stability concerns are addressed. Which can't happen until there's overwhelming proof there's no significant dependency on those TLDs in the huge installed base of crapware that use these today: firewalls, proxy servers, fucked-up corporate nets, IoT, CPE, AD setups, etc. Good luck making that happen before the heat death of the universe.

    2. Michael Wojcik Silver badge

      The PIR / .org / Ethos boondoggle was bad (though ICANN was eventually pressured into killing that deal), but really, who hadn't lost all trust in ICANN after the gTLD expansion that started with dropping most of the rules in 2011? (Or even before that, when they added crap like .job, .travel, and .cat in 2004.) And there was the fiasco over ICANN community members, and many cases of non-transparency and ICANN violating its own bylaws.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like