Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.localhost Domains

inclouds.space

Post reply on HN
Print view View original

111–120 of 212 posts

Re: .localhost Domains

#111

Post by sebazzz »

jeroenhd wrote: post #52
EGreg wrote: post #32

Earlier quoted context omitted.

But is "foo.localhost" a valid domain name, for cookies and such?

The RFC treats .localhost as a full TLD. I believe Windows does as well, as does Ubuntu (using default systemd-resolved), but macOS doesn't seem to resolve .localhost by default, necessitating the host file trickery. Of course, in the early internet, the difference between a TLD and a host name weren't quite as clear as they are right now.

> I believe Windows does as well

I cannot ping xyz.localhost because it doesn't resolve it.

Re: .localhost Domains

#112

Post by qwertox »

smjburton wrote: post #101

OP: If you're already using Caddy, why not just use a purchased domain (you can get some for a few dollars) with a DNS-01 challenge? This way you don't need to add self-signed certificates to your trust store and browsers/devices don't complain. You'll still keep your services private to your internal network, and Caddy will automatically keep all managed certificates renewed so there's no manual intervention once ev…

I was on a similar thought process, but this leaves you only with the option to set the A record of the public DNS entry to 127.0.0.1, if you want to use it on the go.

Though you could register a name like ch.ch and get a wildcard certificate for *.ch.ch, and insert local.ch.ch in the hosts file and use the certificate in the proxy, that would even work on the go.

Re: .localhost Domains

#114

Post by whatevaa »

smjburton wrote: post #101

OP: If you're already using Caddy, why not just use a purchased domain (you can get some for a few dollars) with a DNS-01 challenge? This way you don't need to add self-signed certificates to your trust store and browsers/devices don't complain. You'll still keep your services private to your internal network, and Caddy will automatically keep all managed certificates renewed so there's no manual intervention once ev…

So basically pay protection money? We have engineered such a system that the only way to use your own stuff is to pay a tax for it and rely on centralized system, even though you don't need to be public at all?

Re: .localhost Domains

#115

Post by nsteel »

alexvitkov wrote: post #89
hardaker wrote: post #20

You might check out .internal instead which was recently approved [1] for local use. [1]: https://en.wikipedia.org/wiki/.internal

Too much typing, and Chromium-based browsers don't understand it yet and try to search for mything.internal instead, which is annoying - you have to type out the whole http://mything.internal . This can be addressed by hijacking an existing TLD for private use, e.g. mything.bb :^)

Isn't just typing the slash at the end enough to avoid it searching? e.g. mything/

Re: .localhost Domains

#116

Post by ku1ik »

sigil wrote: post #96

This nginx local dev config snippet is one-and-done: # Proxy to a backend server based on the hostname. if (-d vhosts/$host) { proxy_pass http://unix:vhosts/$host/server.sock; break; } Your local dev servers must listen on a unix domain socket, and you must drop a symlink to them at eg /var/lib/nginx/vhosts/inclouds.localhost/server.sock. Not a single command, and you still have to add hostname resolution. But you do…

This is neat!

Re: .localhost Domains

#117

Post by [deleted] »

thot_experiment wrote: post #93
hobo_mark wrote: post #81

Earlier quoted context omitted.

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?

I alias home.com to my local house stuff. I don't really understand why anyone thinks it's a bad idea either.

[deleted]

Re: .localhost Domains

#118

Post by waynesonfire »

tbyehl wrote: post #108
octagons wrote: post #74

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 rec…

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.

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.

Re: .localhost Domains

#119

Post by donatj »

oulipo wrote: post #78
donatj wrote: post #39

We add a real actual DNS record for the local. subdomain pointing to 127.0.0.1 It works really well and means no setup on our developers machines

Can you expand on this? you redirect *.local.example.com to 127.0.0.1, and then how do you setup the local machine so that eg myservice.local.example.com hits the correct port? I guess you still need a proxy somewhere? or you specify eg myservice.local.example.com:3000 ?

It's not a redirect. It's an actual A record on the domain for local.example.com -> 127.0.0.1

Then we just have an entry for local.example.com in our vhosts and bam everything works as expected. No need to mess with /etc/hosts

Post reply on HN