This makes me think of some AD best practices I read a long time ago. One of the practices was to never use made up local TLDs like .internal or .local because some day they might be real and get picked up by someone.<p>Essentially you should always use a domain you control both outside and inside, like a regular gTLD or ccTLD.<p>Pretty much every single company I've worked for with AD has broken this rule.
.corp, .home and .mail should also be perfectly viable for private use after ICANN eventualy decided to cease all processing of applications for those TLDs.<p><pre><code> "Whereas, on 30 July 2014, the ICANN Board New gTLD Program Committee adopted the Name Collision Management Framework. In the Framework, .CORP, .HOME, and .MAIL were noted as high-risk strings whose delegation should be deferred indefinitely".[1]
</code></pre>
[1] <a href="https://www.icann.org/en/board-activities-and-meetings/materials/approved-board-resolutions-regular-meeting-of-the-icann-board-04-02-2018-en#2.c" rel="nofollow">https://www.icann.org/en/board-activities-and-meetings/mater...</a>
Another possibility is `.zz`, which technically can be a ccTLD but it's a user-assigned ISO 3166-1 alpha-2 code, and its last position makes extremely impossible for it to be repurposed as a valid code even in that setting. In comparison, some user-assigned codes like `XZ` are often used for temporary country codes so `.xz` would be less appropriate.<p>It seems that ICANN did consider this choice among others, but reject for the lack of meaningfulness:<p>> The qualitative assessment on the latter properties was performed in the six United Nations languages (Arabic, Chinese, English, French, Russian and Spanish). [...] Many candidate strings were deemed unsuitable due to their lack of meaningfulness. [...] In this evaluation, only two candidates emerged as broadly meeting the assessment criteria across the assessed languages. These were “INTERNAL” and “PRIVATE”. Some weaknesses were identified for both of these candidates. [...]<p>I wonder if this means that they only scored the highest among others and <i>all</i> candidate strings were indeed unsuitable, but that they had to pick one anyway. I'm not even sure that laypersons can relate `.internal` with the stuff for "internal" uses.
After reading through the threads, I still think that '.lan' is a better non-reserved suffix to use for this than '.internal'; however, my opinion rarely has significant weight in the grand scheme of things.
It would be nice to see this paired with more widespread support for the Name Constraints TLS extension, which would in theory allow internal CAs to be restricted to issuing certificates for .internal domains. That would open up a lot of very interesting applications in terms of streamlining HTTPS on local networks, for example, ACME on openWRT routers.
As others have mentioned there already is the ".home.arpa" TLD but I definitely think ".internal" is a step up in terms of clarity. That said, for my internal network I just put things under a subdomain of a domain I own so I can use HTTPS with a proper SSL cert
I think I would have preferred .intra (Unless it's already used somehow ?).<p>Just 5 letters is less annoying to type repeatedly than .internal, while still conveying the overall purpose relatively well.<p>It might just be my laziness talking though.
ICANN: [Proposed Top-Level Domain String for Private Use](<a href="https://www.icann.org/en/public-comment/proceeding/proposed-top-level-domain-string-for-private-use-24-01-2024" rel="nofollow">https://www.icann.org/en/public-comment/proceeding/proposed-...</a>) "The Internet Assigned Numbers Authority (IANA) has made a provisional determination that “.INTERNAL” should be reserved for private-use and internal network applications(...)"<p>... possibly a better link.
Didn't .local start out this way until it was co-opted by Apple for some network abomination? Any new private domain is just going to get co-opted by something else soon enough. Browser authors and network service authors are going to start using it for random, incompatible purposes and break everything.<p>If you need DNS, register and use a real domain name. Everything else is going to be a hack. Anyone tech-savvy enough to know what an internal, unroutable TLD is, and have a use for one, is going to be just as comfortable and capable of managing a real domain.<p>I support the idea of something like .internal, but I'm certain it will be made useless for its intended purpose in short order.
I'd revently ran into this, after using .local for a long time, and installing something with mdns. Nslookup gave the correct ip, but ping got confused.<p>A quick google did not deliver a decent reserved domain, but multiple people suggested .home
I use .localnet to go with the name of localhost, as this has been suggested by ... one of the RFCs, but I can't remember which.<p>If .localnet ever becomes a real TLD, well, I'm pretty sure the entire global infra is going to collapse and not necessarily be my problem.<p>Edit: And to be clear, I'm doing this for my house, not some enterprise setup; using real actual FQDN for internal services at a company, especially one that is multi-site/cloud, is still the best advice.
At last (or at least soon) I can stop using the special reserved example.com for things. :p<p><a href="https://en.wikipedia.org/wiki/Example.com" rel="nofollow">https://en.wikipedia.org/wiki/Example.com</a>
This is exactly how a committee would design it if none of the participants had actually used an internal domain.<p>For example, in Google, <a href="https://go/foo" rel="nofollow">https://go/foo</a> had "go" as technically a TLD, and the memorable suffix that followed was already part of the path and not the domain name. It made it easy to type or include anywhere, including chats, posters, presentation slides, etc.<p>If they were to follow this proposal instead, you'd be typing or including <a href="https://go.internal/foo" rel="nofollow">https://go.internal/foo</a> , which while more explicit largely defeats the point of the short URL.
If you have a customer and DNS seems to work strangely, have a look if you don't have a so called single-label domain for Active Directory, such as host1.internal or crusty.internal if you have more creative admins or even worse, db.local.
On Windows, the name resolution on single-label domains behaves a bit differently, using NetBIOS resolution which can prevent you from e.g. adding a new host to the domain from a different subnet - you might see this as DNS failure. Of course, it is not DNS's fault, if it wasn't asked in the first place.<p>Here are some more details:
<a href="https://support.microsoft.com/en-us/help/300684/deployment-and-operation-of-active-directory-domains-that-are-configur" rel="nofollow">https://support.microsoft.com/en-us/help/300684/deployment-a...</a>
and
<a href="https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.NetLogon::Netlogon_AllowSingleLabelDnsDomain" rel="nofollow">https://admx.help/?Category=Windows_10_2016&Policy=Microsoft...</a>
which does the DNS resolution even for these less than ideal domains.
The server authentication story is fairly weak. Multiple companies may use the same .internal domain name and none of them can get a TLS certificate from a public certificate authority. This means they'll each need to operate a private CA if they want to authenticate connections to the server (and encrypt with HTTPS). A major problem with this approach is that computers (especially laptops) travel between networks and can end up trusting more than one private CA. This means that you can have multiple servers using the same domain name, but operated by different orgs, and each appears valid to the end user. Session cookies and other data can leak when this happens.<p>I think the right solution is that we should require domain registration (google.internal, microsoft.internal, etc.) to avoid these conflicts. A public CA may be able to verify ownership, avoiding the need for private CAs.<p>I built a service [1] that does this and is compatible with Let's Encrypt. The trick is that I only allow users to set ACME-DNS01 TXT records, not A/AAAA/CNAME records. So you'll still need to run internal DNS for those.<p>[1] <a href="https://www.getlocalcert.net/" rel="nofollow">https://www.getlocalcert.net/</a>
Other currently reserved TLDs:<p><a href="https://en.wikipedia.org/wiki/Top-level_domain#Reserved_domains" rel="nofollow">https://en.wikipedia.org/wiki/Top-level_domain#Reserved_doma...</a>
That's too long. I just bastardize an existing tld on local network like home.net. Some browsers don't even allow made up names. Internal is too long to type.
Stumbled across this thread from 2020 - <a href="https://news.ycombinator.com/item?id=24606723">https://news.ycombinator.com/item?id=24606723</a>
So as others have mentioned there already is the ".home.arpa" TLD;<p>Would the only difference then be the <i>name</i> ".internal" or is there another difference/advantage versus ".home.arpa"?
I can't find it now, but wasn't there a story about microsoft using a 'dummy' url in some internal documents that later became real?
"foo.int/ernal" lookalike attacks in 3… 2… 1…<p>(to be fair, you generally can't get an .int domain registered. "int is considered to have the strictest application policies of all TLDs, as it implies that the holder is a subject of international law.")<p>… now that I think about it, "foo.in/ternal" makes so much more sense …
From the article<p>“ICANN has picked the TLD string that it will recommend for safe use behind corporate firewalls on the basis that it will never, ever be delegated.<p>The string is .internal, and the choice is now open for public comment”<p>Saved you a click :)
Url changed from <a href="https://domainincite.com/29381-icann-picks-the-domain-it-will-never-ever-release" rel="nofollow">https://domainincite.com/29381-icann-picks-the-domain-it-wil...</a>, which points to this.
Personally I use the HOSTS file instead of DNS.<p>Alternatively I use a map file loaded into the memory of a loopback-bound forward proxy. No DNS.<p>I also use loopback-bound authoritative DNS to a limited extent as it provides wildcards.<p>There are ways to avoid using DNS.<p>Most web developers do not understand DNS, or at least dislike it, and some get annoyed by the HOSTS file. Quite funny. But I'm not a developer. DNS is something I understand well enough, I like it, and, in addition, the HOSTS file is useful for me. But sometimes it's most useful for me to avoid DNS.