ICANN proposes creating .INTERNAL domain to do the same job as 192.168.x.x 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 …
Wow. I remember that happening. Brings back memories of 3Com and Novell NetWare drivers for DOS, flaky handmade network cables and pre MDI-X shenanigans.
Does that still happen? I remember it happening back in the day but can’t for the life of me remember it happening in the recent past.
It seemed to be one of those problems that just sort of faded away at some point without even making a dramatic exit scene. Much like some of those annoying Internet commenters on Facebook/twitter don’t.
The 64 character limit for TLDs is really weird. In most cases, a low limit in things is bad because it doesn't take into account future expansion, but seriously, do they think the world will ever be albe to use TLDs of more than like, 12 characters, at the very most? The whole point of DNS is to make addresses human-readable. Is every device on Earth supposed to get its own TLD, which will have to contain random alphanumeric strings? Is every personal TLD going to look like AOL email addresses, with random numbers added to your name? Will the current concept of domain names and TLDs even apply if your personal TLD is equivalent to your email address and assigned at birth?
It seems like a fine limit to me. We may not use anything that long, but having a lower limit wouldn't offer any advantages as far as I know. The 64-character limit also makes it possible to use some strange things, like the encoding of Unicode domains to ASCII. The longest domain name in use is .ファッション, which is in your expected range for length, but since it's in unicode, it's actually implemented as .xn--bck1b9a5dre4c. It's convenient that the limit makes that feasible, as a shorter limit would have required it to be truncated.
You'll be kicking yourself for this comment when Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch becomes its own country.
Mind you, at 58 letters long, when using the English alphabet, it's already too long to be coded in the Welsh alphabet via punycode, so I propose the limit is raised to 128 characters!
But they won't be speaking Welsh in the new Democratic People's Republic of Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch! They'll be speaking Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogochian. And who knows how many letters they'll choose to have in their alphabet?
They'll also have the biggest delegations at international conferences. Because they'll need to have three people sat next to the ambassador, just in order to fill the table space covered by the name plaque. Or I suppose they could just get some really fat ambassadors?
Their fans chants for their national sports teams will be interesting too. Give me an L! Give me another L! Give me a...
Country code TLDs are only two characters... Although I suppose if we move to unicode for those, as mentioned by another, they could technically be a few characters longer. There just comes a point where the reason for DNS existing is somewhat eliminated by letting the domain names become so long that they take an appreciable amount of time to type.
That 128 characters isn't long enough for กรุงเทพมหานคร อมรรัตนโกสินทร์ มหินทรายุธยา มหาดิลกภพ นพรัตนราชธานีบูรีรมย์ อุดมราชนิเวศน์มหาสถาน อมรพิมานอวตารสถิต สักกะทัตติยวิษณุกรรมประสิทธิ์ and even less for the transliteration in the Latin alphabet (Krungthepmahanakhon Amonrattanakosin Mahintharayutthaya Mahadilokphop Noppharatratchathaniburirom Udomratchaniwetmahasathan Amonphimanawatansathit Sakkathattiyawitsanukamprasit).
Reminds me of my friend’s name.
When his boxes arrived at university it blew me away that his full name - transcribed directly on to the cardboard in bold caps in thick black marker, as was requested by the university - wrapped around three sides of his boxes over four lines deep.
It's not a limit on TLDs, specifically, it's on any "label" part of a DNS name.
For a fully-qualified DNS name like part1.part2.part3, any of part1, part2, or part3 (each considered a "label) must be no more than 64 characters, but there's no inherent limit on how many parts you can use.
This is baked into DNS software and tools everywhere, and it would take literally decades to change due to the number of things that need to handle DNS names.
"For a fully-qualified DNS name like part1.part2.part3, any of part1, part2, or part3 (each considered a "label) must be no more than 64 characters, but there's no inherent limit on how many parts you can use."
Nope. And nope.
The maximum length of a DNS label is 63 characters. The maximum length of a domain name is 255 characters (including the dots between the labels). The effective maximum length of a domain name is 253 characters because the wire format includes a dot and NUL character after the right-most label. These are usually not shown when a fully qualified domain name is displayed to carbon-based life forms. The two characters are there however. They're part of the protocol encoding of a domain name.
What if it's a domain that crosses multiple physical locations, connected by WAN services and VPN?
LAN is also close to the newer top level domain of LAND so there could be a risk of mistakes. The new list of domains is ridiculous and such a cash-grab by ICANN. I just saw that .kim is a TLD. The relevance to the Internet? It's a Korean surname, so OBVIOUSLY it deserves to be a top level domain name. Kim and Wang are the only surnames in the list, but wang can at least also be a rendering of a word meaning "web" or "portal" so it's meaningful in Chinese.
The new list of domains is ridiculous and such a cash-grab by ICANN.
Yes, they are ridiculous. And stupid. And pointless. But they were not a cash-grab by ICANN. Most of the ~$200k-a-pop gTLD application fees paid to ICANN got spunked up against the wall on the independent consultants and lawyers who assessed the gTLD bids.
The actual cash-grab was done by the hucksters who made money fa$$$t flogging these new domain names to an all too gullible public, fleecing easily fooled VCs, stiffing naive newbies to the DNS business, etc, etc. Or any combination of these scams.
I just saw that .kim is a TLD. The relevance to the Internet?
Good question. Some idiot clearly thought it was worth spending hundreds of thousands of dollars to get .kim. It must have been relevant to them. Even if the rest of the Internet didn't.
I didn't know that. Years ago I chose a 2 letter domain root that wasn't used for an existing country and so far the various wars and disputes haven't spawned a new country that wants to use it. I'm not going to re-jig my DNS server to a new standard though. Sometimes being different is useful.
"Hello, hello. What's going on? What's all this shouting? We'll have no trouble here."
Well, actually, multicast DNS (mDNS, also known as Bonjour, Avahi, etc) requires quite a bit of shouting, otherwise none of the devices in a .local network will know how to find each other…
(I'll get my coat, and any other precious things, and leave…)
You can blame Microsoft for the large number of corporate internal networks that use [company].local as their Active Directory domain, because at one point they recommended it (according to wikipedia, anyway.)
I will be honest, I have no idea how difficult changing the name of an Active Directory is after it's been created, and I'm a little leery of trying it. (It's probably be easier to stand up a new one and migrate everyone over. )
It is possible to change an AD namespace, but you really don't want to do it, especially if you have Exchange servers.
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc816848(v=ws.10)
I tried it once with a brand new AD where the client changed their mind. SQL server broke. Fortunately as it didn't have anything on it at the time, I just rebuilt it.
The .local domain name is reserved for an entirely different purpose:
https://datatracker.ietf.org/doc/html/rfc6762
...but I too have had to deal with environments that have used it for internal purposes, usually thanks to SBS.
I have had many arguments with people who don't want to listen to the advice that they should be using a subdomain of their registered domain name as their AD namespace. The only other acceptable option being another registered domain name they are not using for internet facing purposes.
To ensure that it remains globally unique.
What wasn't realy stated well in the article is that people often just pick something that's not registered and use that. The problem is that if someone comes along and registers it, you now have a conflict. At it's best, no-one in your internal domain can reach anything public in the newly registered version of it - that may not matter at all, or it may be a big PITA if it's something important to your business. But also, stuff tends to leak - so your internal domain name will tend to leak through various means such that people outside of your business try to reach it for one of many reasons. While it's not registered such attempts fail, once it's registered then "interesting" things can happen - such as your customers finding themselves on another business's website. Come to think of it, a competitor could register the domain for that reason.
So it makes sense to make sure that whatever you use is something that will never ever cause confusion - such as belonging to a different business.
If .internal can never be registered as a global TLD, then no matter how many people use company.internal for their internal domain name, it will never matter to anyone else. There becomes no reason to register a domain name to use for your internal domain, and no ABILITY to register company.internal as a global domain name. Uniqueness becomes irrelevant. Any updated DNS server will never attempt to contact any other DNS server, including the root, to talk about that TLD. That's the whole point of this proposal. To finally officially define an internal TLD that can never be globally recognized, which only became an issue when ICANN opened up the ability to create anything as a gTLD as before that it could be assumed that anything not in the gTLD list never would be.
You know how every bit of Microsoft documentation about setting up AD has always said to use a specific domain which is not your web address?
Well whoever set up the AD at my last job never read it. Nope, they'd set it up as companyname.co.uk, which was already causing problems when I started there, let alone during my job :(
You can blame Microsoft for the large number of corporate internal networks that use [company].local as their Active Directory domain, because at one point they recommended it
Yes they did, and I can remember "strongly suggesting" that using it in the manner suggested by MS was breaking things. Needless to say my Windows server building colleagues ignored any internet standard that didn't agree with what MS said and carried on using it. I do recal that as a Mac user, I couldn't access things via Bonjour (Apple's name for mDNS) without (from vague memory) doing something like adding ".local" to some setting in the network->Interface->DNS panel.
In fact, .local is already reserved by the IETF and IANA for essentially this purpose (apparently not specifically for use with internal DNS servers, but rather mDNS, but it's what has been done for decades and has always been the default in Windows). Does ICANN just feel like they need to be seen to be doing something, and it can't be just agreeing with some other organization, so they are willing to fragment the ecosystem and make it more confusing? Or are they deciding they're going to "fix" what they see as being used incorrectly by everyone?
No. Using .local in as a DNS TLD can cause problems because of precisely the reason you cite - it's officially used by mDNS and as mDNS configurations "own" that TLD, using it in the local DNS will cause issues if you're network also runs mDNS.
For this reason, it's already prohibited from being used in the DNS.
Its a bit more nuanced than "don't use it"
From Wiki
"At one time, Microsoft at least suggested the use of .local as a pseudo-TLD for small private networks with internal DNS servers. For example, support article 296250[5] included the following option:
Make the name a private domain name that is used for name resolution on the internal Small Business Server network. This name is usually configured with the first-level domain of .local. At the present time, the .local domain name is not registered on the Internet."
and IETF also allow for that use - same ref as above.
"Any DNS query for a name ending with the label local must be sent to the mDNS IPv4 link-local multicast address 224.0.0.251, or its IPv6 equivalent ff02::fb. A domain name ending in .local may be resolved concurrently via other mechanisms, for example, unicast DNS."
so although use of .local for the local domain is permitted, such may cause issues in particular setups... I wonder when RFC 6762 was written compared to the recommendation to use .local for private non-internet connected networks?
Any DNS query for a name ending with the label local must be sent to the mDNS IPv4 link-local multicast address 224.0.0.251, or its IPv6 equivalent ff02::fb
Which means it cannot, safely, be used for the purpose .INTERNAL is meant for: .local is controlled by the devices on a LAN - anything which can answer the multicast DNS query the fastest controls what names appear in .local and what addresses they resolve to. .INTERNAL is controlled by the organisations DNS servers - they decide who can resolve .INTERNAL and hence what those names resolve to.
Imagine an org which sets up some sort of access control granting access to all devices in *.local: an attacker with access to the LAN just needs to resolve their "attacker.local" address to get access. If they use .INTERNAL then the attacker needs to gain control of the orgs actual DNS servers to gain access.
I think you're confusing link-local (where .local works perfectly as part of mDNS) and site-local (where people want to define stuff in the site-local part of split-horizon DNS). .local will not work in split-horizon DNS. server.internal.example.com already works well in split-horizon DNS. server.internal will save typing, that's all. It's pretty pointless.
but rather mDNS,
Initially, mDNS was broken by use of .local for internal DNS. It's still incompatible. By design. The allocation of .local to mDNS was done by people who thought that all domains should be global, and that people who disagreed with them shouldn't be allowed to use the internet. FWIW, these are the same people who told us that NAT was immoral, and who gave us globally addressable IPv6 as the alternative.
The problem ICANN is addressing is that the "globally accessible servers" people haven't entirely won: there are still .local domains, and people who want to use mDNS still want local domains
This post has been deleted by its author
.local has been grabbed by someone at Apple (I believe) for their mdns / bonjour service, thus damaging a lot of people that used .local as their internal domain. Nowadays the resolver libraries tend to send out mdns broadcast requests for .local and don't as the dns server at all, making it unsuitable for use.
Yes, they have overlooked the key usability factors of laziness and brevity! ".lan" is nice and short and quick for admins to type when needed, ".internal" not so much (and if they actually make it case-sensitive .INTERNAL, yuck…!).
I'd even go so far as to suggest why not assign .zz for this: it's a two-letter TLD not currently in use, and I suspect that it's unlikely that it would ever be needed for a real country (indeed, there are now slightly fewer ccTLDs (and countries) beginning with Z than there used to be)…
Zanzibar could have ended up with that if it was fully autonomous, and still might want it if they ever did go off on their own again, so really you can never tell what some new country name might end up being and what other combinations might be available that will make sense. There are only 676 combinations of English letters and nearly 200 recognized countries right now, with 308 ccTLDs already designated.
So basically, ICANN wants to make a standard out of something everyone can already do and some are doing it, but ICANN wants to put a specific name on it which will make everyone already doing it wonder if they should go through the hassle of changing and decide not to. But future network admins may buy into the "standard", except if that contradicts some business requirement, in which case they'll just go with whatever they need and it'll work anyway.
Did I get that right ?
Not even that. ICANN has, over years of discussion, decided to take a name and do nothing with it. A name they already were doing nothing with, that nobody had asked to use, and in a set of other names they've already decided to do nothing with. When this idea is fully implemented, nothing whatsoever will change anywhere in the world.
Unlikely, I think (hope!). The resolver libraries have no idea what the scope of ".INTERNAL" is supposed to be in any particular organisation. One org might give it site-wide meaning, another might give it company-wide meaning.
Over time I presume that resolvers will gain configuration options to control/limit where .INTERNAL names can be sent for resolution. For now, the decision just guarantees that if the name reaches the root servers it will not resolve.
Fair enough, I was being sloppy with my terminology. The point I was trying to make is that the DNS systems will be set up to treat it as special and stop it at the edge of an organisation in the way they won't for other domains.
Theoretically, this could happen. Equally theoretically, they could already do this for any number of names. They could be configured to look for *.internal.companyname.co.uk and drop it. They could be configured to drop any internal domain the admins might set up and drop that. Either way, though, some admin will have to configure their internal DNS resolvers to know when they should be dropping requests that have not resolved yet and when to forward them on, and if they don't do that, the request will still go to the external DNS system. All this does is ensure that the external systems will reject it. However, since .internal didn't already exist, those external systems already would reject it.
The root servers should never accept anything except the specific TLDs that have been defined by the IANA and ICANN. ICANN is trying to define something that is already defined, in that respect. All that will really change here is that they create an official definition that .internal can NEVER be turned into a TLD that can be used globally, and suggesting that everyone should use it internally. No other DNS server should accept any records for a non-standard TLD being sent to it by any other DNS server unless it's specifically part of the domain involved or configured to trust that DNS server.
No, it's not, because they actually do use most or all IP addresses. If we hadn't reserved the 10.0.0.0/8 block, some ISP would have asked for and been granted it, and we wouldn't be able to use it. In addition, it's quite intrinsic to the way networks are used that IP addresses be available for local use without having to request them from someone else, and private addresses permit this.
Let's consider both aspects with the .internal name. Nobody has requested .internal, and it's unlikely anyone would given how many new TLDs have been issued. Any TLD that does not exist can be created without registration, will be dropped by public DNS, and can be filtered by internal DNS infrastructure.
Two reasons. Mostly that the land rush has come and gone. When lots of people were buying up names, there was more of a chance that that would happen, but many of those names have not proven to be the commercial blockbusters the investors were hoping for and they're busy hosting cheap domains for scammers and the occasional domain hack, but not even a fun one as was done with two-letter TLDs. Some of them have even been shut down entirely. I don't think people are still hoping to throw money into that.
The second reason is that ICANN already decided that some TLDs were not to be reserved. Back in 2018, they put several TLDs on the never list because some internal systems had used them. If .internal was already used frequently, I would expect ICANN to reject the application should someone try to reserve it after all. I don't have any objection to them doing this, but it's weird for them to make it sound like they've done a lot of work when they have no technology to set up.
Exactly. That's the reason for putting it on the reserved list. There are mentions of using .internal in this way in IETF documents going back many years (2017 at least).
But if it was actually important, the IETF would have added it to the registry some while ago, I think:
https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml
New laws that everyone must allow ICANN IP addresses through their firewalls to scan the network to check for domain names in use to make sure you're not illicitly using .internal without a license, and count how many machines are on your network so they can charge per-device.
This has been resisted for so long, and was so obviously needed.
I have .lan at home mainly as OpenWRT uses this and it's quicker to type than .internal.
To be honest I'd reserve common ones used (identified in the report) and not just one, then just move on.
i.e. .home, .internal, .lan, .corp, .localdomain
I can see it actually being more sensible for an AD domain to be companyname.{corp|lan|internal} than a real (as recommended by MS).
Companies often forget to renew real domains (then your are stuck).
Would that have made a difference, unless it was done a few decades prior, perhaps even when the original gTLDs were defined? At that time, nobody was thinking that the gTLDs would be expanded with every random word or partial word that someone could justify or bribe an official to allow, so there wasn't a concern about ad-hoc domains overlapping because everybody knew which ones couldn't be used. Once any amount of time had passed where there was no conception that it would be an issue, ad-hoc internal domains were already being used and the sudden vomit of new ones was going to be a problem already.
One of the clients at my last job even had a .com internal domain that matched a real outside domain that WASN'T THEIRS. The dumbass that set them up used their company initials, for made-up example IIN.com as their internal domain because the company was International In Nature, but their website had to be intin.com because the website bin.com belonged to Breaking Into Numerics. It made maintaining their DNS so much of a pain whenever we wanted to set up a server that was accessible from the outside and the inside, or changed ISPs or IP addresses because they had an Exchange server plus the other public servers.
This post has been deleted by its author
Which is why The Register loves the standards process
My quick and dirty duckduckgo-ing netted me some references in example unbound configs, but not what the domain is. Didn't search the unbound repos (don't feel like logging into github, couldn't find the template config file in a quick peruse of the files), but an answer may be there
I've got a github login. It seems to be associated with a list maintained by "Chris Buijs", containing top level domains that do not exist, yet are frequently queried.
From "https://github.com/cbuijs/accomplist.git"
$ git grep zghjccbob3n0 | grep -i chris | grep -vE ".{1000}"
chris/abuse-tlds.list:zghjccbob3n0
chris/dnsmasq-abuse-tld.conf:server=/zghjccbob3n0/
tlds/black.list:zghjccbob3n0 Chris-Abuse-TLDS
tlds/dnsmasq-filter.conf:server=/zghjccbob3n0/ # Chris-Abuse-TLDS
tlds/dnsmasq-regex-filter.conf:server=/zghjccbob3n0/ # Chris-Abuse-TLDS
tlds/knot-daf.conf:daf.add 'qname = zghjccbob3n0 deny' -- Chris-Abuse-TLDS
tlds/plain.skipped.invalid.domain.list:zghjccbob3n0 # Invalid-TLD-Chris-Abuse-TLDS
tlds/unbound-filter.conf: local-zone: "zghjccbob3n0" always_nxdomain # Chris-Abuse-TLDS
$
I believe its an artifact of Google Chrome, when some severly developmentally disabled Chromium developer thought that querying a random (ha) string sans .TLD every second was a good idea. It was only when this reached the real world that DNS owners started receiving a shitstorm of garbage dns queries that were traced back to said developer at Google.
I know of a former employer that have all their AD on a subdomain of ".int" and don't (and can never) own that .int domain name.
In fact, I don't think I've yet seen a production system use a proper internal domain yet, surviving only by convention and chance, or using their ".com" name from the outset instead (which is fine until companies merge...).
What do you define as a "proper internal domain"? Up to this point, anything that wasn't already defined as a valid global TLD has been considered acceptable, if you didn't want to make it match your public website domain (something I never understood the need or desire to do even when Microsoft started recommending it).
.int sounds okay to me, as it's very unlikely to ever be requested as a new gTLD.
".int sounds okay to me, as it's very unlikely to ever be requested as a new gTLD."
The problem is that .int is already a GTLD, one of the relatively early ones. It's for international organizations, and it's quite strict about it. For example, the official website for the United Nations is un.int. The EU has a few of them, but they usually redirect to something.europa.eu. In practice, it's not as likely to cause a problem as using some other existing domain you don't control just because it's quite difficult to get a .int domain so it's unlikely that any other system will exist and your DNS request will just fail, but still, not the best idea.
Doh, I missed it in the list of the original ones, and have never actually seen one in use since even organizations that should be using something restricted usually end up using a more common one like .com or .net.
But still, what do you consider "proper"? Until the flood from ICANN, anything that wasn't in the list of official global domains was considered perfectly okay because nobody expected random words to ever be made global. And using anything like company.local is just as much of a problem for merging companies as company.com would be.
Ahhh, you're too young to remember the free fax service by "the phone company" @ tpc.int !
This post has been deleted by its author
I've been using .loc on LANs for decades. Please give us TLAs for these generic private TLDs. .loc (screw mDNS, you can't have .loc. Not yours.) .prv and might as well make .private for those that hate TLAs and like typing more than you need to for getting things done.
This post has been deleted by its author
I wasn't quite clear what this proposal entailed. I suppose I could read ICANN's proposal docs and I could alsk chew off my right arm but I am not certain that the later wouldn't be less painful. ;)
The desire to never register INTERNAL. as a TLD wouldn't require little more than an administrative policy decision I would have thought.
My guess the root servers are hammered with futile queries for ad hoc site local domains which the common DNS software cannot, because they are ad hoc, be constructed or preconfigured by default to *never* forward to the root servers. Settling on a single INTERNAL. site local TLD means BIND and its ilk can treat this TLD specially and never forward queries to the root servers (and hopefully never outside the site.) Any external name server can also reply with an error (nxdomain?) when queried with a .INTERNAL request.
Personally I used BIND's views and TSIGs to run separate name services for the world subset of the full world + internal name service. Include files kept a single instance of each resource record. Never actually required the equivalent of INTERNAL. A the scale involved (~1000 A records with < 50 world and fairly static) this was low maintenance but an order of magnitude larger probably not.
The topology, names etc of the network had zero security concerns - mainly the good hygiene of not wanting rfc1918 addresses pointlessly resolved externally. Admittedly VPNs added a whole new level of misery. :(
This post has been deleted by its author
Why else would they have made it allowable to create basically anything as a domain? As far as I can tell, being able to afford the fees and prove you have the money to maintain it are the only requirements. No need to show there's an actual need for it, that many people want it, etc. It's primarily a cash-grab by ICANN, enabled by letting registrars create a land-grab where everyone is concerned about their own trademarks being registered on a popular gTLD. The explanations of needing additional domain name availability because so many second-level domains (even non-trademarks) on the main gTLDs were already taken is just a small justification.
Can anyone explain what the costs are being referred to here are: "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."
The costs of documenting and maintaining these brain-dead (and generally unnecessary) setups.
The costs of operating/debugging/fixing a weird DNS setup that nobody really understands.
The costs of untangling name collisions when 2 or more organisations have to merge their previously disjoint .internal name spaces. Think corporate mergers or restructuring.
The costs of working around crapware that claims .internal (or whatever) doesn't exist even though it does. Sort of. Locally.
The costs of cleaning up these shit-shows and getting rid of the bozos responsible for creating them.
The costs of making your .internal (or whatever) work once some blockchain/DHT/insert-new-shiny-here has a brain fart and chooses to anchor their global name space under that pseudo-TLD. This has happened at least twice in recent years, albeit not with .internal.
Moral of the story: don't pluck domain names or TLDs out of your arse. Ever. Use names that you can be certain are globally unique and not "owned" by anyone else. For some definition of "owned". This new .internal thingummy can't provide those guarantees. So use it at your own risk, hopefully with a full appreciation for the consequences.
The entire point of the new ".internal thingummy" is to ensure that it can never be owned by anyone. It ensures that .internal will NEVER be set up as a global TLD, so no matter if every company in the world set up company.internal as their internal domain name, the only time it could ever become an issue is if two companies tried to federate their domains, merge them into one, or something like that, or for some dumbass reason let their DNS servers send records to each other.
Also the very definition of "plucking domain names or TLDs out of your arse" is making up names you can be certain are globally unique. Where else are you going to get unique names if you don't pluck them out of your ass? Any TLD you choose that is not on the current gTLD list COULD be added to it later on, even if you think it's a random combination of letters (except .local since that's also prohibited globally but is meant for mDNS so it can cause other issues). Using only numbers for your TLD should be okay, but nothing's to say the rule on that couldn't be changed to allow it as gTLDs.
None of your arguments actually mean anything that is unique to the use of .internal.
This post has been deleted by its author
The millions of companies that have been using their own chosen TLDs internally for decades, usually .local, without any problems, would also like ICANN to explain their FUD on that. I'm guessing it's a threat that the TLD you choose to use internally could one day get turned into a live gTLD due to ICANN making it possible for any string of characters, whether it's a word or company name or nothing, to be created by someone who has enough money for it, thus making it possible for your company's name or something like it to be used in a way you don't like, so you'll feel a need to register things to try to keep the damage to a minimum. That was always a possibility with the regular gTLDs, but the new ones exploded the risk since now your company name could be registered in another 300 gTLDs. But using your existing public domain name doesn't eliminate that risk either, and the majority of companies, even those with websites, don't do anything that would ever need their internal network to be connected to the DNS for their public domain in any significant way. Even using Exchange doesn't require it, and I found it was much MORE work as an IT person to manage a client's systems when they did match.
Perhaps these days with all the near-forced cloud integration, they're referring to it being costlier to try to maintain them separately even when you have zero reason to have anything in the cloud.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
