Live data from Hacker News

.localhost Domains

inclouds.space

31–40 of 212 posts

Re: .localhost Domains

#32
post #8

Wow! Today I learned that you can have subdomains of localhost. Never realized it!

.localhost is in the same list as .example and .invalid when it comes to reserved names: https://datatracker.ietf.org/doc/html/rfc2606 It's a neat trick, but it comes with some caveats. For instance, `localhost` often resolves to both 127.0.0.1 and ::1, but `.localhost` is described in RFC2606 as "traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP addr…

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

Re: .localhost Domains

#33
I pondered the question of local-only domains since long ago, and in consultation with Chris Siebenmann, I determined that the most courteous way was actually to subdomain from my ISP.

That’s right: I invented a fictitious subdomain under one my ISP controlled and I never registered it or deployed public DNS for it. It worked great, for my dumb local purposes.

Example:

  aten.mysub.isp.net.
  porta.mysub.isp.net.
  smartphone.mysub.isp.net.
Thus it was easy to remember, easy to add new entries, and was guaranteed to stay out of the way from any future deployments, as long as my ISP never chose to also use the unique subdomain tag I invented...

Re: .localhost Domains

#34
post #5

Avoid using `.local`. In my experience Chrome does not like it with HTTPS. It takes much much longer to resolve. I found a Chrome bug relating to this but do not have it handy to share. `.localhost` makes more sense for local development anyways.

Honestly, if I had my druthers there would be a standardized exception for .local domains that self-signed HTTPS certs would be accepted without known roots. It's insane how there's no good workflow for HTTPS on LAN-only services.

Re: .localhost Domains

#35

I haven't done it for a while (I've mostly just used 127.*), but I found the best one to use for dev purposes was the IETF-reserved `.test` TLD [0]. The main benefit at the time I was messing with this (10ish years ago now) was that all the browsers I needed to test on would actually attempt to resolve `.test`. If I remember correctly, firefox seemed to have issues with `localhost` being anything other than 127.0.0.1…

.test seems like an excellent choice for testing/debugging/developing applications, but for running services you want to use I'd stick to .internal these days, as it was reserved for local domains last year.

Re: .localhost Domains

#36
We have a separate domain registered, where you can add any wildcard subdomain, so webui.company-test.com and that will resolve to 127.0.0.1. Then we can do pretty much the same.

I'm not entirely sure how I feel about it, but at least it's on a completely separate domain.

Re: .localhost Domains

#37

I haven't done it for a while (I've mostly just used 127.*), but I found the best one to use for dev purposes was the IETF-reserved `.test` TLD [0]. The main benefit at the time I was messing with this (10ish years ago now) was that all the browsers I needed to test on would actually attempt to resolve `.test`. If I remember correctly, firefox seemed to have issues with `localhost` being anything other than 127.0.0.1…

For development, "localhost" has a convenience bonus: it has special treatment in browsers. Many browser APIs like Service Workers are only available on pages with a valid WebPKI cert, except for localhost.

Re: .localhost Domains

#38
post #30

Anyone care to shed why myapp.localhost:3000 (for the webapp I'm developing) is something that's useful for me rather than localhost:3000 ? EDIT: on linux and don't use launchd, so I'd still the port number

Using real domain names lets you experience the web as it is in production. Localhost has a bunch of exceptions (i.e. HTTP URLs are treated as secure, CORS acts funny, etc.). Using domain names disables special handling of localhost URLs that'll help you spot problems before they hit production.

Re: .localhost Domains

#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

Re: .localhost Domains

#40
post #30

Anyone care to shed why myapp.localhost:3000 (for the webapp I'm developing) is something that's useful for me rather than localhost:3000 ? EDIT: on linux and don't use launchd, so I'd still the port number

[deleted]
Post reply on HN