←back to thread

.INTERNAL is now reserved for private-use applications

(www.icann.org)
563 points joncfoo | 1 comments | 09 Aug 24 16:36 UTC | HN request time: 0.219s | source
Show context
8organicbits ◴[09 Aug 24 22:03 UTC] No.41205729[source]▶
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.

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.

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.

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

replies(12): >>41206030 #>>41206106 #>>41206231 #>>41206513 #>>41206719 #>>41206776 #>>41206828 #>>41207112 #>>41208240 #>>41208353 #>>41208964 #>>41210736 #
layer8 ◴[10 Aug 24 12:19 UTC] No.41208964[source]▶
I don’t understand the frustration. The use of .internal is explicitly for when you don’t want a publicly valid domain. Nobody is forcing anyone to use .internal otherwise.
replies(2): >>41209199 #>>41210387 #
pas ◴[10 Aug 24 13:10 UTC] No.41209199[source]▶
the frustration comes when non-corporate-provisoned clients get on the .internal network and have trouble using the services because of TLS errors (or the problem is lack of TLS)

and the recommendation is to simply do "*.internal.example.com" with LetsEncrypt (using DNS-01 validation), so every client gets the correct CA cert "for free"

...

obviously if you want mTLS, then this doesn't help much. (but still, it's true that using a public domain has many advantages, as having an airgapped network too)

replies(2): >>41209307 #>>41209508 #
1. 8organicbits ◴[10 Aug 24 13:51 UTC] No.41209508[source]▶
I'll add that anyone using VMs or containers will also run into trust issues too without extra configuration. I've seen lots of contractors resort to just ignoring certificate warnings instead of installing the corporate certs for each client they work with.