←back to thread

563 points joncfoo | 2 comments | | HN request time: 0.414s | source
Show context
tetris11 ◴[] No.41205044[source]
I need a dumbed down version of this.
replies(7): >>41205276 #>>41205281 #>>41205313 #>>41205394 #>>41205523 #>>41208597 #>>41208986 #
quectophoton ◴[] No.41205523[source]
When you need to assign an IP address for a host, the safest thing to do is to either use an IP address you own^Ware renting, or to use an IP address nobody will be able to "own" in the foreseeable future.

This is that but for domain names. When you need to use a domain name to refer to a host, the safest thing to do is to either use a domain name you own^Ware renting, or to use a domain name nobody will be able to "own" in the foreseeable future.

For an IP address, you might usually choose from 192.168.0.0/16 or similar reserved ranges. Your "192.168.1.1" is not the same as my "192.168.1.1", we both can use it and neither of us can "officially" own it.

For a domain name, you can use ".internal" or other similar (if uglier) reserved TLDs. Your "nas.internal" is not the same as my "nas.internal", we both can use it and neither of us can "officially" own it.

Since you're asking this question you might also be wondering how people can even use custom domains like that, and the answer is by self-hosting a DNS server, and using that as a DNS server instead of a public one (so you'd use your self-hosted server instead of, say, "8.8.8.8"). Then you configure your DNS server so that whenever someone requests "google.com" it does "the normal thing", but when someone requests "nas.internal" it returns whatever IP address you want.

replies(1): >>41207041 #
ninkendo ◴[] No.41207041[source]
There’s similar discussions about this in other threads, but I’ve taken to just using a real domain name (lan.<my-vanity-domain>.me) even for my house stuff, but otherwise doing something like you say above.

The advantage is that I can run real letsencrypt certs for services in my house, which is nicer than having to agree to self signed cert warnings or otherwise having my browser nag me about plaintext passwords/etc.

If anyone cares about the details, I run an nginx instance on port 80 through an ipv6 address which I allow through my network firewall (no NAT, so I don’t have to burn my only incoming ipv4 port 80 for this, although I block that anyway) and let certbot manage its configs. Wildcard external dns pointing AAAA records to said v6 address. The certbot vhost just renders an empty 404 for all requests except for the ACME challenges, so there’s nothing being “leaked” except generic 404 headers. I get certs dumped to my nginx config dir, then from there I use them for an internal-only reverse proxy listening on my local subnet, for all my internal stuff. The only risk is if I mess up the config and expose the RP to the internet, but so far I haven’t managed to screw it up.

replies(1): >>41207742 #
1. PokestarFan ◴[] No.41207742[source]
Why not just use ACME DNS?
replies(1): >>41208655 #
2. ninkendo ◴[] No.41208655[source]
Because this setup works fine, and I haven’t bothered getting to that level of automation with my external DNS provider.