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

121–130 of 212 posts

Re: .localhost Domains

#121

Post by jrockway »

joey_spaztard wrote: post #99

This is an ok way of doing things but you don't need Caddy server (or similar), you can put all the http servers on different localhost ip addresses eg 127.0.0.1, 127.0.0.2, etc. They can all use port 80 but on different ip addresses. A possible disadvantage is that specifying a single ip to listen on means the http server won't listen on your LAN ip address, which you might want.

The last time I tried this, it works on Linux but not on Mac OS. Given all the discussion about launchd, I'm guessing they need it to work on Macs.

Re: .localhost Domains

#122

Post by mjevans »

WorldMaker wrote: post #66
mjevans wrote: post #44

Earlier quoted context omitted.

Yes, but why couldn't they have assigned .mdns for that instead? Or even better given it it's own .arpa domain? E.G. .mdns(.arpa) rather than the .local TLD? ( https://en.wikipedia.org/wiki/.arpa )

Because .local looks nice and is a better name/explainer for what mDNS does than the standard name or the old brand name? Because the old brand was already using .local even if Apple Devices were somewhat a minority at the time? At this point a lot of TLD changes are going to step on someone's project or home/business/private network. I think .local is a good name for mDNS. I appreciate why you maybe aren't happy wit…

Those are both reasons that .local should be static DNS on the _network_ like localhost is a standard name for the loopback address(es).

There's no reason .mdns or .mdns.arpa couldn't have just been added to the default domains search list (the list of suffixes tried for non FQDN searches); which given it ISN'T a nice human obvious word to append wouldn't have conflicted with anyone who'd already had a .local at the time, and anyone else in the future who thinks an obvious phrase like .local would not be in use by some other resolver system.

Re: .localhost Domains

#123

Post by smjburton »

shadowpho wrote: post #110
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…

> 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/.

Re: .localhost Domains

#124

Post by jwilk »

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…

> Any subdomain of .localhost works out-of-the-box on Linux

No, not here.

Re: .localhost Domains

#125

Post by ghoshbishakh »

jeroenhd wrote: post #38
vlod wrote: 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.

Trick: edit yuor /etc/hosts file and add a domain name.

Self sign a certificate and add it to your trusted certificate list.

Or - use https://pinggy.io

Re: .localhost Domains

#126

Post by smjburton »

whatevaa wrote: post #114
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?

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 cheap domain. It's also less of a headache in my experience.

Re: .localhost Domains

#127

Post by jwilk »

MaKey wrote: post #87
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

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.

Re: .localhost Domains

#128

Post by fimdomeio »

Shywim wrote: post #80
oulipo wrote: post #71

Earlier quoted context omitted.

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

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

Re: .localhost Domains

#129

Post by jchw »

jwilk wrote: post #124
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…

> Any subdomain of .localhost works out-of-the-box on Linux No, not here.

This usually happens because you have a Linux setup that doesn't use systemd-resolved and it also doesn't have myhostname early enough in the list of name resolvers. Not sure how many Linux systems default to this, but if you want this behavior, adjust your NSS configuration, most likely.

Re: .localhost Domains

#130

Post by radlad »

GrumpyYoungMan wrote: post #60
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

The *.home.arpa domain in RFC 8375 has been approved for local use since 2018, which is long enough ago that most hardware and software currently in use should be able to handle it.

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 the project might be dead: https://openwrt.org/docs/guide-user/network/zeroconfig/hncp_...

Anyone familiar with HNCP? Are there any concerns of conflicts if HNCP becomes "a thing"? I have to say, .home.arpa doesn't exactly roll of the tongue like .internal. Some macOS users seem to have issues with .home.arpa too: https://www.reddit.com/r/MacOS/comments/1bu62do/homearpa_is_...

Post reply on HN