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

141–150 of 212 posts

Re: .localhost Domains

#141

Post by tedunangst »

oulipo wrote: post #71
WhyNotHugo wrote: post #50

Any subdomain of .localhost works out-of-the-box on Linux, OpenBSD and plenty of other platforms. Of note, it doesn't work on macOS. I recall having delivered a coding assignment for a job interview long ago, and the reviewer said it didn't work for them, although the code all seemed correct to them. It turned out on macOS, you need to explicitly add any subdomains of .localhost to /etc/hosts. I'm still surprised by…

Just did that on my mac and it seems to work? $ ping hello.localhost PING hello.localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.057 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.162 ms

That's because your DNS server sends back 127.0.0.1. The query isn't resolved locally.

Re: .localhost Domains

#142

Post by hn92726819 »

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…

I'm not that familiar with nginx config. Does this protect against path traversal? Ex: host=../../../docker.sock

Re: .localhost Domains

#143

Post by sigil »

hn92726819 wrote: post #142
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…

I'm not that familiar with nginx config. Does this protect against path traversal? Ex: host=../../../docker.sock

nginx validates hostnames per the spec, and to your question specifically it rejects requests that would put a slash in $host: https://github.com/nginx/nginx/blob/b6e7eb0f5792d7a52d2675ee...

Re: .localhost Domains

#144

Post by eddyg »

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

.home, .corp and .mail are on ICANN’s “high risk” list so won’t ever be gTLDs, so they are also good (short) options.

Ref: https://www.icann.org/en/board-activities-and-meetings/mater...

Re: .localhost Domains

#145

Post by aib »

jchw wrote: post #28
lima wrote: post #14

On my Linux machine with systemd-resolved, this even works out the box: $ resolvectl query foo.localhost foo.localhost: 127.0.0.1 -- link: lo ::1 -- link: lo Another benefit is being able to block CSRF using the reverse proxy.

Yeah, I've been using localhost domains on Linux for a while. Even on machines without systemd-resolved, you can still usually use them if you have the myhostname module in your NSS DNS module list. https://www.man7.org/linux/man-pages/man8/libnss_myhostname.... (There are lots of other useful NSS modules, too. I like the libvirt ones. Not sure if there's any good way to use these alongside systemd-resolved.)

I ended up writing a similar plugin[1] after searching in vain for a way to add temporary DNS entries.

The ability to add host entries via an environment variable turned out to be more useful than I'd expected, though mostly for MITM(proxy) and troubleshooting.

1: https://github.com/aib/nss-userhosts

Re: .localhost Domains

#146

Post by octagons »

hobo_mark wrote: post #81
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…

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?

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.

Re: .localhost Domains

#147

Post by egoisticalgoat »

smjburton wrote: post #126
whatevaa wrote: post #114

Earlier quoted context omitted.

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?

If you really want to keep things local without paying any fees, you could also use Smallstep ( https://smallstep.com/ ) to issue certificates for your services. This way you only need to add one CA to your trust store on your devices, and the certificates still renew periodically and satisfy the requirements for TLS. I suggested using a domain given they already have Caddy set up and it's inexpensive to acquire a ch…

If you're already adding a CA to your trust store, you can just use caddy! [0] Add their local CA to your store (CA cert is valid for 10 years), and it'll generate a new cert per local domain every day.

Actually, now that I've linked the docs, it seems they use smallstep internally as well haha

[0] https://caddyserver.com/docs/automatic-https#local-https

Re: .localhost Domains

#148

Post by lxgr »

sangeeth96 wrote: post #79
CodesInChaos wrote: post #75

Earlier quoted context omitted.

How do valid certs for localhost work? Does that require installing an unconstraint root certificate to sign the dev certs? Or is there a less risky way (name constraints?)

It's mentioned in the README: - If Caddy has not already generated a local root certificate: - Generate a local root certificate to sign TLS certificates - Install the local root certificate to the system's trust stores, and the Firefox certificate store if it exists and an be accessed. So yes. I had written about how I do this directly with Caddy over here: https://automagic.blog/posts/custom-domains-with-https-for-…

> Install the local root certificate to the system's trust stores

I really wish there was a safer way to do this, i.e. a way to tag a trusted CA as "valid for localhost use only". The article mentions this in passing

> The sudo version of the above command with the -d flag also works but it adds the certificate to the System keychain for all users. I like to limit privileges wherever possible.

But this is a clear case of https://xkcd.com/1200/.

Maybe this could be done using the name constraint extension marked as critical?

Re: .localhost Domains

#149

Post by octagons »

waynesonfire wrote: post #118
tbyehl wrote: post #108

Earlier quoted context omitted.

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.

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/

Re: .localhost Domains

#150

Post by [deleted] »

tepmoc wrote: post #103
alexvitkov wrote: post #89

Earlier quoted context omitted.

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 :^)

eh, you can just add search domain via dhcp or static configuration and just type out http://mything/ no need to enter whole domain unless you need todo ssl

[deleted]
Post reply on HN