Would have prefered "*.int"
I would have preferred a shortened version, a la ".int" rather than ".internal".
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 …
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
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.
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.
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.
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.
This post has been deleted by its author
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?
"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?
> 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.
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...
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.
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!"
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.
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.
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.
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!
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.
> 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.
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.)
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.)
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.
> 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?
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?
"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.
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?
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.
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.
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?
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.
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.