←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.214s | 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 #
layer8 ◴[10 Aug 24 13:26 UTC] No.41209307[source]▶
You’re basically saying that .internal can cause frustration when it is used without good reason. Fair enough, but also not surprising. When it is used for the intended reasons though, then there’s just no other solution. It’s a trade-off between conflicting goals. “Simply do X instead” doesn’t remove the trade-off.
replies(1): >>41210211 #
nightpool ◴[10 Aug 24 15:34 UTC] No.41210211[source]▶
What do you see as the intended reasons with no other solutions?
replies(3): >>41210534 #>>41210948 #>>41211076 #
8organicbits ◴[10 Aug 24 16:24 UTC] No.41210534[source]▶
The biggest benefit of .internal IMO is that it is free to use. Free domains used to be a thing, but after the fall of Freenom you're stuck with free subdomains.
replies(1): >>41211663 #
powersnail ◴[10 Aug 24 19:30 UTC] No.41211663[source]▶
If `.internal` is for private-use only, they must be resolved by some sort of private or internal DNS. In that case, all domains are free for private-use anyway.
replies(1): >>41212267 #
1. 8organicbits ◴[10 Aug 24 21:18 UTC] No.41212267[source]▶
Unfortunately, that's not true in general. Google proved this with their handling of the .dev TLD. Security settings like the HSTS preload list can impact your internal network if you "squat" on a domain you don't own. Google added all of .dev to the HSTS preload list and now, if you use any domain under that, you browser will force you to use HTTPS.