from Hacker News

Proposed top-level domain string for private use: ".internal"

by zacwest on 1/27/24, 3:45 AM with 229 comments

  • by INTPenis on 1/27/24, 7:10 AM

    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.

    Essentially you should always use a domain you control both outside and inside, like a regular gTLD or ccTLD.

    Pretty much every single company I've worked for with AD has broken this rule.

  • by traceroute66 on 1/27/24, 3:29 PM

    .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.

        "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]
    [1] https://www.icann.org/en/board-activities-and-meetings/mater...

  • by lifthrasiir on 1/27/24, 8:49 AM

    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.

    It seems that ICANN did consider this choice among others, but reject for the lack of meaningfulness:

    > 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. [...]

    I wonder if this means that they only scored the highest among others and all 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.

  • by LeoPanthera on 1/27/24, 5:41 AM

    Also worth noting that "home.arpa" is already reserved and specifically designed for residential use. It will never conflict with anything.

  • by tensility on 1/27/24, 12:43 PM

    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.

  • by nbadg on 1/27/24, 12:16 PM

    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.

  • by mezzode on 1/27/24, 8:30 AM

    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

  • by loupol on 1/27/24, 7:23 AM

    I think I would have preferred .intra (Unless it's already used somehow ?).

    Just 5 letters is less annoying to type repeatedly than .internal, while still conveying the overall purpose relatively well.

    It might just be my laziness talking though.

  • by gnabgib on 1/27/24, 4:57 AM

    ICANN: [Proposed Top-Level Domain String for Private Use](https://www.icann.org/en/public-comment/proceeding/proposed-...) "The Internet Assigned Numbers Authority (IANA) has made a provisional determination that “.INTERNAL” should be reserved for private-use and internal network applications(...)"

    ... possibly a better link.

  • by caymanjim on 1/27/24, 5:20 PM

    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.

    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.

    I support the idea of something like .internal, but I'm certain it will be made useless for its intended purpose in short order.

  • by hyperman1 on 1/27/24, 9:55 AM

    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.

    A quick google did not deliver a decent reserved domain, but multiple people suggested .home

  • by DiabloD3 on 1/27/24, 7:56 AM

    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.

    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.

    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.

  • by Terr_ on 1/27/24, 4:59 AM

    At last (or at least soon) I can stop using the special reserved example.com for things. :p

    https://en.wikipedia.org/wiki/Example.com

  • by icedchai on 1/27/24, 2:02 PM

    I use a subdomain of “int” for all internal hosts: host.int.example.com. My internal machines have int.example.com and example.com in the search path.

  • by fl0ki on 1/27/24, 4:37 PM

    This is exactly how a committee would design it if none of the participants had actually used an internal domain.

    For example, in Google, https://go/foo 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.

    If they were to follow this proposal instead, you'd be typing or including https://go.internal/foo , which while more explicit largely defeats the point of the short URL.

  • by tracker1 on 1/27/24, 10:36 AM

    I think imternal, .lan, .inside should all be reserved and established to never allow registration with OCANN.

  • by fmajid on 1/27/24, 8:56 AM

    This may generate confusion with the .int gTLD used for international organizations like UN agencies.

  • by kaliszad on 1/27/24, 11:21 PM

    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.

    Here are some more details: https://support.microsoft.com/en-us/help/300684/deployment-a... and https://admx.help/?Category=Windows_10_2016&Policy=Microsoft... which does the DNS resolution even for these less than ideal domains.

  • by 8organicbits on 1/27/24, 1:26 PM

    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.

    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.

    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.

    [1] https://www.getlocalcert.net/

  • by w-ll on 1/27/24, 7:05 AM

    since ".dev" was hijacked ive been using ".lan" and ".lab"

  • by greatgib on 1/27/24, 12:12 PM

    So sad that a big tech company stole the dot dev thanks to the ICANN greediness...

  • by NoZebra120vClip on 1/27/24, 4:08 AM

  • by dingi on 1/28/24, 5:29 AM

    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.

  • by dkpk on 1/27/24, 10:33 AM

    Stumbled across this thread from 2020 - https://news.ycombinator.com/item?id=24606723

  • by DavideNL on 1/31/24, 11:04 AM

    So as others have mentioned there already is the ".home.arpa" TLD;

    Would the only difference then be the name ".internal" or is there another difference/advantage versus ".home.arpa"?

  • by p1mrx on 1/27/24, 5:05 AM

    Eh, .internal is fine, but it's 8 characters to type. I'll probably keep using .lan until someone else takes it.

  • by matt3210 on 1/27/24, 5:45 AM

    .local already does this

  • by whycome on 1/27/24, 6:53 PM

    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?

  • by gmuslera on 1/27/24, 12:51 PM

    What about ssl? will that work with i.e. letsencrypt?

  • by rickette on 1/27/24, 7:04 AM

    host.docker.internal

  • by Arch-TK on 1/27/24, 5:41 PM

    I just use i.slow.network as my internal domain. Most things support search domains to avoid having to type too much.

  • by throwawaaarrgh on 1/27/24, 2:31 PM

    If it doesn't get accepted I'll use .arpanet because nobody's registering that

  • by denkmoon on 1/27/24, 9:17 AM

    .lan thanks.

  • by m3drano on 1/30/24, 1:21 PM

    it seems to cover the whole RFC 1918 (IPv4) and 4193 (IPv6), so not only 192.168.0.0/16 like some media indicated.

  • by amne on 1/27/24, 6:45 AM

    .intranet ?

  • by VoodooJuJu on 1/27/24, 2:56 PM

    Why did this take so long?

  • by eqvinox on 1/27/24, 5:06 PM

    "foo.int/ernal" lookalike attacks in 3… 2… 1…

    (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.")

    … now that I think about it, "foo.in/ternal" makes so much more sense …

  • by lodovic on 1/27/24, 5:11 PM

    Please allow self-signed certificates for ".internal" by default

  • by vmurthy on 1/27/24, 4:36 AM

    From the article

    “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.

    The string is .internal, and the choice is now open for public comment”

    Saved you a click :)

  • by dang on 1/27/24, 6:13 AM

  • by 1vuio0pswjnm7 on 1/27/24, 9:46 AM

    Personally I use the HOSTS file instead of DNS.

    Alternatively I use a map file loaded into the memory of a loopback-bound forward proxy. No DNS.

    I also use loopback-bound authoritative DNS to a limited extent as it provides wildcards.

    There are ways to avoid using DNS.

    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.