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

201–210 of 212 posts

Re: .localhost Domains

#201

Post by jFriedensreich »

globular-toast wrote: post #187
jFriedensreich wrote: post #25

Chrome and i think Firefox resolve all .localhost domains to localhost per default, so you don't have to add them to the hosts file. I setup a docker proxy on port 80 that resolves all requests from .localhost to the first exposed port of that container (in order of appearing in the docker compose file) automatically which makes everything smooth without manual steps for docker compose based setups.

Source for this? Are you sure it's not your system resolver doing it?

Pretty sure its hard coded in the browser and never touches any resolvers. It does not work the same in safari for example.

Re: .localhost Domains

#202

Post by g0db1t »

jwilk wrote: post #127
MaKey wrote: post #87

Earlier quoted context omitted.

It seems like it has not been standardized yet: > As of March 7, 2025, the domain has not been standardized by the Internet Engineering Task Force (IETF), though an Internet-Draft describing the TLD has been submitted.

It's been reserved by ICANN: https://www.icann.org/en/board-activities-and-meetings/mater... > Resolved (2024.07.29.06), the Board reserves .INTERNAL from delegation in the DNS root zone permanently to provide for its use in private-use applications.

> Resolved (2024.07.29.06) ... I'm too tired, I read it as a IPv4 adress...

Re: .localhost Domains

#203

Post by g0db1t »

fimdomeio wrote: post #128
Shywim wrote: post #80

Earlier quoted context omitted.

Not for me, MacOS 15.4: $ ping hello.localhost ping: cannot resolve hello.localhost: Unknown host

I think I had mixed results on mac depending on the network I was connected to. I think it has something to do with ipv4 vs ipv6

Ironically for me it works on my MacOS laptop but not on my Debian 12 VPS

Re: .localhost Domains

#204

Post by g0db1t »

justin_oaks wrote: post #133
nine_k wrote: post #105

BTW you can actually give every locally-hosted app a separate IP address if you want. The entire 127.0.0/24 is yours, so you can resolve 127.0.0.2, 127.0.0.3, etc as separate "hosts" in /etc/hosts or in your dnsmasq config. Yes, this also works under macOS, but I remember there used to be a need to explicitly add these addresses to the loopback interface. Under Linux and (IIRC) Windows these work out of the box.

I'd recommend using some other reserved IP address block like 169.254.0.0/16 or 100.64.0.0/16 and assigning it to your local loopback interface. (Nitpick: you can actually use all of 127.0.0.0/8 instead of just 127.0.0.0/24). I previously used differing 127.0.0.0/8 addresses for each local service I ran on my machine. It worked fine for quite a while but this was in pre-Docker days. Later on I started using Docker co…

I have no idea why this is not the default solution nor why Docker can not engage in it?

Re: .localhost Domains

#205

Post by [deleted] »

justin_oaks wrote: post #133
nine_k wrote: post #105

BTW you can actually give every locally-hosted app a separate IP address if you want. The entire 127.0.0/24 is yours, so you can resolve 127.0.0.2, 127.0.0.3, etc as separate "hosts" in /etc/hosts or in your dnsmasq config. Yes, this also works under macOS, but I remember there used to be a need to explicitly add these addresses to the loopback interface. Under Linux and (IIRC) Windows these work out of the box.

I'd recommend using some other reserved IP address block like 169.254.0.0/16 or 100.64.0.0/16 and assigning it to your local loopback interface. (Nitpick: you can actually use all of 127.0.0.0/8 instead of just 127.0.0.0/24). I previously used differing 127.0.0.0/8 addresses for each local service I ran on my machine. It worked fine for quite a while but this was in pre-Docker days. Later on I started using Docker co…

[deleted]

Re: .localhost Domains

#207

Post by shadowpho »

smjburton wrote: post #123
shadowpho wrote: post #110

Earlier quoted context omitted.

> You'll still keep your services private to your internal network, Is that a new thing? I heard previously that if you wanted to do DNS/domain for local network you had to expose the list external.

It's not, just a different way of satisfying the certificate challenge. Look into a DNS-01 challenge vs a HTTP-01 challenge. Let's Encrypt has a good breakdown: https://letsencrypt.org/docs/challenge-types/ .

Gotcha and that lets us avoid to expose internals? that seems like a win win win, I should totally do this!

Re: .localhost Domains

#209

Post by jrvieira »

wutwutwat wrote: post #184
jrvieira wrote: post #179

Earlier quoted context omitted.

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

1. not all browsers are the same they are all aiming to implement the same html spec 2. there is no official standard there literally is > A context is considered secure when it meets certain minimum standards of authentication and confidentiality defined in the Secure Contexts specification https://w3c.github.io/webappsec-secure-contexts/ 3. even if there was, standards are often ignored major browsers wouldn't be m…

Secure contexts, not a part of the html spec, are described in the w3c candidate recommendation, which I can assume you are calling the official standard, which states:

>5.1. Incomplete Isolation > >The secure context definition in this document does not completely isolate a "secure" view on an origin from a "non-secure" view on the same origin. Exfiltration will still be possible via increasingly esoteric mechanisms such as the contents of localStorage/sessionStorage, storage events, BroadcastChannel, and others.

>5.2. localhost > >Section 6.3 of [RFC6761] lays out the resolution of localhost. and names falling within .localhost. as special, and suggests that local resolvers SHOULD/MAY treat them specially. For better or worse, resolvers often ignore these suggestions, and will send localhost to the network for resolution in a number of circumstances. > >Given that uncertainty, user agents MAY treat localhost names as having potentially trustworthy origins if and only if they also adhere to the localhost name resolution rules spelled out in [let-localhost-be-localhost] (which boil down to ensuring that localhost never resolves to a non-loopback address).

>6. Privacy Considerations > >The secure context definition in this document does not in itself have any privacy impact. It does, however, enable other features which do have interesting privacy implications to lock themselves into contexts which ensures that specific guarantees can be made regarding integrity, authenticity, and confidentiality. > >From a privacy perspective, specification authors are encouraged to consider requiring secure contexts for the features they define.

This does not qualify as the "this" in my original comment.

Re: .localhost Domains

#210

Post by novoreorx »

peterldowns wrote: post #68

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…

After reading this blog, I immediately thought of Localias. I use it frequently, preferring the .test domain.
Post reply on HN