Most active commenters
  • octagons(3)

←back to thread

.localhost Domains

(inclouds.space)
301 points todsacerdoti | 11 comments | | HN request time: 0s | source | bottom
1. octagons ◴[] No.43645228[source]
Against much well-informed advice, I use a vanity domain for my internal network at home. Through a combination Smallstep CA, CoreDNS, and Traefik, any services I host in my Docker Swarm cluster automatically are immediately issued a signed SSL certificate, load-balanced, and resolvable. Traefik also allows me to configure authentication for any services that I may not wish to expose without such.

That said, I do recommend the use of the internal. zone for any such setup, as others have commented. This article provides some good reasons why (at least for .local) you should aim to use a standards-compliant internal zone: https://community.veeam.com/blogs-and-podcasts-57/why-using-...

replies(2): >>43645339 #>>43645906 #
2. hobo_mark ◴[] No.43645339[source]
I added a fake .com record in my internal DNS that resolves to my development server. All development clients within that network have an mkcert-generated CA installed.

Not so different from you, but without even registering the vanity domain. Why is this such a bad idea?

replies(4): >>43645645 #>>43645706 #>>43648413 #>>43651367 #
3. thot_experiment ◴[] No.43645645[source]
I alias home.com to my local house stuff. I don't really understand why anyone thinks it's a bad idea either.
replies(2): >>43645764 #>>43646379 #
4. szszrk ◴[] No.43645706[source]
For home it's not that bad, but there could be conflicts at some point. Your clients will send data to the Internet unknowingly when dns is missconfigured.

It's better to use domain you control.

I'm a fan of buying cheapest to extend (like .ovh, great value) and use real Let's Encrypt (via dns challenge) to register any subdomain/wildcard. So that any device will have "green padlock" for totally local service.

5. matthewaveryusa ◴[] No.43645764{3}[source]
It's not a terrible idea. On a large scale it can lead to the corp.com issue:

https://krebsonsecurity.com/2020/02/dangerous-domain-corp-co...

Honestly for USD5/year why don't you just buy yourself a domain and never have to deal with the problem?

6. tbyehl ◴[] No.43645906[source]
What's the argument against using one's own actual domain? In these modern times where every device and software wants to force HTTPS, being able to get rid of all the browser warnings is nice.
replies(1): >>43646410 #
7. ◴[] No.43646379{3}[source]
8. waynesonfire ◴[] No.43646410[source]
I think this is ideal. You make a great point that even if you were to use .internal TLD that is reserved for internal use, you wouldn't be able to use letsencrypt to get a SSL certificate for it. Not sure if there are other ssl options for .internal. But, self-signed is a PITA.

I guess the lesson is to deploy a self-signed root ca in your infra early.

replies(1): >>43648734 #
9. octagons ◴[] No.43648413[source]
To be clear, I didn’t register anything. I just have a configuration that serves records for a zone like “artichoke.” on my DNS server. Internal hosts are then accessible via https://gitlab.artichoke, for example.
10. octagons ◴[] No.43648734{3}[source]
Check out Smallstep’s step-ca server [0]. It still requires some work, but it allows you to run your own CA and ACME server. I have nothing against just hosting records off of a subdomain and using LE as mentioned, but I personally find it satisfying to host everything myself.

[0] https://smallstep.com/docs/step-ca/

11. kreetx ◴[] No.43651367[source]
I run a custom (unused) tld with mkcert the same way, with nginx virtual hosts set up for each app.