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."
(Score: 5, Insightful) by Revek on Thursday February 01, @12:52PM (8 children)
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)
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
Only if you first liquefy the bits and then coagulate the bytes.
(Score: 0) by Anonymous Coward on Thursday February 01, @02:23PM
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)
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
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
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)
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
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]
(Score: 4, Insightful) by WizardFusion on Thursday February 01, @02:06PM (12 children)
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)
They could have used a shorter name that has emoji characters.
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 5, Funny) by Opportunist on Thursday February 01, @02:54PM (3 children)
Leave. Now.
And don't forget to drop your geek card into the incinerator provided on the way out.
(Score: 4, Insightful) by Mojibake Tengu on Friday February 02, @03:49AM (2 children)
Or they could made a completely new emoji for just that...
Respect Authorities. Know your social status. Woke responsibly.
(Score: 2) by Opportunist on Friday February 02, @11:38PM
I'll make sure to name my next ulcer after you.
(Score: 2) by The Vocal Minority on Sunday February 04, @04:36AM
An emoji for dropping your geek card in the incinerator?
(Score: 0) by Anonymous Coward on Thursday February 01, @02:56PM (1 child)
They could have also used .ANAL, that's LAN with an A.
(Score: 2) by VLM on Friday February 02, @12:53PM
Its "LAN A" read backwards because its for reverse DNS.
(Score: 3, Informative) by hendrikboom on Thursday February 01, @07:07PM
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
UNIX? They're not even circumcised! Savages!
(Score: 2) by Unixnut on Thursday February 01, @10:01PM
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
….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
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
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)
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)
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.
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 2) by DannyB on Thursday February 01, @11:28PM
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.
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 3, Interesting) by Rosco P. Coltrane on Thursday February 01, @09:17PM (1 child)
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: 2) by takyon on Thursday February 01, @10:10PM
If it prevents just one network engineer from dropping their spaghetti and their pants and exposing themselves to the world, it will have been worth it.
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 3, Interesting) by boltronics on Friday February 02, @03:49AM
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
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