Live data from Hacker News

.localhost Domains

inclouds.space

171–180 of 212 posts

Re: .localhost Domains

#171

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

It would be great if there was an easy way to get trusted certificates for reserved domains without rolling out a CA. There are a number of web technologies that don't work without a trusted HTTPS origin, and it's such a pain in the ass to add root CAs everywhere.

You can configure them to send requests through http proxy.

Re: .localhost Domains

#172
I too made a version of this (just a small Go DNS resolver + port forwarding proxy) that lets you do a similar thing: https://gitlab.com/amedeedabo/zoxy

I used the .z domain bc it's quick to type and it looks "unusual" on purpose. The dream was to set up a web UI so you wouldn't need to configure it in the terminal and could see which apps are up and running.

Then I stopped working the job where I had to remember 4 different port numbers for local dev and stopped needing it lol.

Ironically, for once it's easier to set this kind of thing up on MacOS than on Linux, bc configuring a local DNS resolver on linux (cf this taiscale blog post "The Sisyphean Task Of DNS Client Config on Linux" https://tailscale.com/blog/sisyphean-dns-client-linux). Whereas on Mac it's a couple commands.

I think Tailscale should just add this to their product, they already do all the complicated DNS setup with their Magic DNS, they could sprinkle in port forwarding and be done. It'd be a real treat.

Re: .localhost Domains

#173

I use .localhost for all my projects. Just one annoying note: Safari doesn't recognize the TLD localhost so it will try to perform a search. Adding a slash at the end will fix this; ie example.localhost/

Luckily the easy fix is available: Do not use Safari.

Re: .localhost Domains

#174

If you’re interested in doing local web development with “real” domain names, valid ssl certs, etc, you may enjoy my project Localias. It’s built on top of Caddy and has a nice CLI and config file format that you can commit to your team’s shared repo. It also has some nice features like making .local domain aliases available to any other device on your network, so you can more easily do mobile device testing on a rea…

There is also mkcert by Filippo Valsorda (no relation to mkcert.org) at https://github.com/FiloSottile/mkcert

Re: .localhost Domains

#175
post #115

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

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

mything/ will make the OS resolve various hosts: mything., mything.local (mDNS), mything.whateverdomainyourhomenetworkuses. (which may be what you wanted).

If you want to be sure, use mything./ : the . at the end makes sure no further domains are appended during DNS lookup, and the / makes the browser try to access to resource without Googling it.

Re: .localhost Domains

#176
post #131

Earlier quoted context omitted.

Technically speaking you could use DANE with mDNS. Nobody does it, browser don't implemented it, but you can follow the spec if you'd like. Practically speaking, HTTPS on LAN is essentially useless, so I don't see the benefits. If anything, the current situation allows the user to apply TOFU to local devices by adding their unsigned certs to the trust store.

> HTTPS on LAN is essentially useless Public wifi isn't a thing? Nobody wants to admin the router on a wifi network where there might be untrusted machines running around?

Sure, but you can connect those devices to a real domain and use Let's Encrypt on them, or you can TOFU and add the self-signed cert to your browser; after you've verified that you're not being MitM'd by one of those untrusted devices, of course (I dunno, by printing the public key on the side of the device or something?).

In practice, you probably want an authorized network for management, and an open network with the management interface locked out, just in case there's a vulnerability in the management interface allowing auth bypass (which has happened more often than anyone would like).

Re: .localhost Domains

#177
post #59

Earlier quoted context omitted.

Technically speaking you could use DANE with mDNS. Nobody does it, browser don't implemented it, but you can follow the spec if you'd like. Practically speaking, HTTPS on LAN is essentially useless, so I don't see the benefits. If anything, the current situation allows the user to apply TOFU to local devices by adding their unsigned certs to the trust store.

Some more modern browser APIs only work in HTTPS. That's why I had to do it.

Modern browsers only enable those APIs because of security concerns, and those security concerns aren't lifted just because you're connected locally.

The existing exception mechanisms already work for this, all you need to do is click the "continue anyway" button.

Re: .localhost Domains

#178

Earlier quoted context omitted.

broken link

Docs at https://docs.orbstack.dev/docker/domains Forgot to add .local I see

I hope Orbstack is also advertising those hostnames on mDNS, because using .local (or, seemingly worse, _relying_ on .local) will conflict with resolver logic on all kinds of devices.

Re: .localhost Domains

#179
post #155

Note: browsers also give you a Secure Context for .localhost domains. https://developer.mozilla.org/en-US/docs/Web/Security/Secure... So you don't need self signed certs for HTTPS on local if you want to, for example, have a backend API and a frontend SPA running at the same time talking to eachother on your machine (authentication for example requires a secure context if doing OAuth2).

Well shit. TIL. Time to go reduce the complexity of our dev environment.

you should never trust browsers default behavior

1. not all browsers are the same

2. there is no official standard

3. even if there was, standards are often ignored

4. what is true today can be false tomorrow

5. this is mitigation, not security

Re: .localhost Domains

#180
post #130

Earlier quoted context omitted.

RFC 8375 seems to have approved it specifically to use in Home Networking Control Protocol, though it also states "it is not intended that the use of 'home.arpa.' be restricted solely to networks where HNCP is deployed. Rather, 'home.arpa.' is intended to be the correct domain for uses like the one described for '.home' in [RFC7788]: local name service in residential homenets." The OpenWrt wiki on Homenet suggests th…

Check the errata for RFC 7788. .home being listed in it is a mistake. .home has never been designated for this purpose. home.arpa is for HNCP. Use .internal.

I have been commandeering .home for the boxes on my LAN since forever. Why change it?

If I were going to do a bunch of extra work messing with configs I'd be far more inclined to switch all my personal stuff over to GNS for security and privacy reasons.

Post reply on HN