←back to thread

.INTERNAL is now reserved for private-use applications

(www.icann.org)
563 points joncfoo | 5 comments | 09 Aug 24 16:36 UTC | HN request time: 1.265s | 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 #
prussian ◴[10 Aug 24 02:12 UTC] No.41206828[source]▶
Just be mindful that any certs you issue in this way will be public information[1] so make sure the domain names don't give away any interesting facts about your infrastructure or future product ideas. I did this at my last job as well and I can still see them renewing them, including an unfortunate wildcard cert which wasn't me.

[1] https://crt.sh/

replies(3): >>41206969 #>>41208715 #>>41208926 #
Helmut10001 ◴[10 Aug 24 02:52 UTC] No.41206969[source]▶
Just use wildcard certs and internal subdomains remain internal information.
replies(2): >>41207432 #>>41210084 #
qmarchi ◴[10 Aug 24 05:04 UTC] No.41207432[source]▶
There's a larger risk that if someone breaches a system with a wildcard cert, then you can end up with them being able to impersonate _every_ part of your domain, not just the one application.
replies(3): >>41207849 #>>41208648 #>>41209814 #
qwertox ◴[10 Aug 24 14:35 UTC] No.41209814[source]▶
I issue a wildcard cert for *.something.example.com.

All subdomains which are meant for public consumption are at the first level, like www.example.com or blog.example.com, and the ones I use internally (or even privately accessible on the internet, like xmpp.something.example.com) are not up for discovery, as no public records exist.

Everything at *.something.example.com, if it is supposed to be privately accessible on the internet, is resolved by a custom DNS server which does not respond to `ANY`-requests and logs every request. You'd need to know which subdomains exist.

something.example.com has an `NS`-record entry with the domain name which points to the IP of that custom DNS server (ns.example.com).

The intranet also has a custom DNS server which then serves the IPs of the subdomains which are only meant for internal consumption.

replies(1): >>41210531 #
1. brewmarche ◴[10 Aug 24 16:24 UTC] No.41210531[source]▶
This is the DNS setup I’d have in mind as well.

Regarding the certificates, if you don’t want to set up stuff on clients manually, the only drawback is the use of a wildcard certificate (which when compromised can be used to hijack everything under something.example.com).

An intermediate CA with name constraints (can only sign certificates with names under something.example.com) sounds like a better solution if you deem the wildcard certificate too risky. Not sure which CA can issue it (letsencrypt is probably out) and how well supported it is

replies(1): >>41211498 #
2. qwertox ◴[10 Aug 24 19:03 UTC] No.41211498[source]▶
I'm "ok" with that risk. It's less risky than other solutions, and there's also the issue that hijacked.something.example.com needs to be resolved by the internal DNS server.

All of this would most likely need to be an inside job with some relatively big criminal energy. At that level you'd probably also have other attack vectors which you could consider.

replies(1): >>41214165 #
3. Helmut10001 ◴[11 Aug 24 05:28 UTC] No.41214165[source]▶
This is also my thinking.. if someone compromises your VM that is responsible for retrieving wildcard certs from let's encrypt, then you're probably busted anyway. Such a machine would usually sit at the center of infrastructure, with limited need to be connected to from other machines.
replies(1): >>41217059 #
4. brewmarche ◴[11 Aug 24 15:53 UTC] No.41217059{3}[source]▶
Probably most people would deem the risk negligible, but it’s still worth to mention it, since you should evaluate for yourself. Regarding the central machine: the certificate must not only be generated or fetched (which as you said probably will happen “at the center”) but also deployed to the individual services. If you don’t use a central gateway terminating TLS early the certificate will live on many machines, not just “at the center.”
replies(1): >>41231672 #
5. Helmut10001 ◴[13 Aug 24 02:41 UTC] No.41231672{4}[source]▶
You are absolutely right. And deployment can be set up to open up additional vulnerabilities and holes. But there are also many ways to make the deployment quite robust (e.g. upload via push to a deploy server, distribute from there). ... and just by chance, I've written a small bash script that helps to distribute SSL certificates from a centrally managed "deploy" server 8) [1].

[1]: https://github.com/Sieboldianus/ssl_get