My biggest frustration with .internal is that it requires a private certificate authority. Lots of organizations struggle to fully set up trust for the private CA on all internal systems. When you add BYOD or contractor systems, it's a mess.<p>Using a publicly valid domain offers a number of benefits, like being able to use a free public CA like Lets Encrypt. Every machine will trust your internal certificates out of the box, so there is minimal toil.<p>Last year I built getlocalcert [1] as a free way to automate this approach. It allows you to register a subdomain, publish TXT records for ACME DNS certificate validation, and use your own internal DNS server for all private use.<p>[1] <a href="https://www.getlocalcert.net/" rel="nofollow">https://www.getlocalcert.net/</a>
Are there any good reasons to use a TLD like .internal for private-use applications, rather than just a regular gTLD like .com?<p>It's nice that this is available, but if I was building a new system today that was internal, I'd use a regular domain name as the root. There are a number of reasons, and one of them is that it's incredibly nice to have the flexibility to make a name visible on the Internet, even if it is completely private and internal.<p>You might want private names to be reachable that way if you're following a zero-trust security model, for example; and even if you aren't, it's helpful to have that flexibility in the future. It's undesirable for changes like these to require re-naming a system.<p>Using names that can't be resolved from the Internet feels like all downside. I think I'd be skeptical even if I was pretty sure that a given system would not ever need to be resolved from the Internet. [Edit:] Instead, you can use a domain name that you own publicly, like `example.com`, but only ever publish records for the domain on your private network, while retaining the <i>option</i> to publish them publicly later.<p>When I was leading Amazon's strategy for cloud-native AWS usage internally, we decided on an approach for DNS that used a .com domain as the root of everything for this reason, even for services that are only reachable from private networks. These services also employed regular public TLS certificates too (by default), for simplicity's sake. If a service needs to be reachable from a new network, or from the Internet, then it doesn't require any changes to naming or certificates, nor any messing about with CA certs on the client side. The security team was forward-thinking and was comfortable with this, though it does have tradeoffs, namely that the presence of names in CT logs can reveal information.
Bunch more discussion on the proposal earlier in the year:<p><i>Proposed top-level domain string for private use: ".internal"</i><p><a href="https://news.ycombinator.com/item?id=39152306">https://news.ycombinator.com/item?id=39152306</a>
I think it is good to have a .internal TLD for internal use.<p>(I also think that a .pseudo TLD should be made up which also cannot be assigned on the internet, but is also not for assigning on local networks either. Uusually, in the cases where it is necessary to be used, either the operating system or an application program will handle them, although the system administrator can assign them manually on a local system if necessary.)
[...] the Board reserves .INTERNAL from delegation in the DNS root zone permanently to provide for its use in private-use applications. The Board recommends that efforts be undertaken to raise awareness of its reservation for this purpose through the organization's technical outreach.
Ever since this kind of stuff was introduced I've been annoyed that there is no way to disable it for yourself. And it's allowed for straight up evil stuff like google buying the .dev TLD
There used to be issues with the public part of a .com getting sent weird private windows traffic iirc. This was discovered with honeypot analysis and the potential for information exposure if you could register a .com and another company was using it as their AD domain.
Is there an appliance or offline service to setup a private CA, do secure remote attestation, and issue certificates only to authenticated peers? Also preferably with fido2 support for administrative purposes.
Now we just wait until browsers stop doing a search if you type anything ending with .internal, which is the biggest issue with using non standard private domains.