Live data from Hacker News

.localhost Domains

inclouds.space

161–170 of 212 posts

Re: .localhost Domains

#161

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?

I run a custom (unused) tld with mkcert the same way, with nginx virtual hosts set up for each app.

Re: .localhost Domains

#162
post #130

Earlier quoted context omitted.

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

Re: .localhost Domains

#163
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.

Re: .localhost Domains

#164
It's easy with Caddy to setup it in a way that you can have your api and SPA app in under the same domain in order to avoid CORS-issues.

myapp.localhost { tls internal

    # Serve /api from localhost:3000 (your API)
    @api path /api/*
    handle @api {
        # Remove the leading "/api" portion of the path
        uri strip_prefix /api
        reverse_proxy 127.0.0.1:3000
    }

    # Fallback: proxy everything else to Vite's dev server on 5173
    handle {
        reverse_proxy 127.0.0.1:5173
    }
}

You're welcome.

Re: .localhost Domains

#165
post #154
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…

> I have to say, .home.arpa doesn't exactly roll of the tongue like .internal. In my native language (Finnish) it's even worse, or better, depending on personal preference - it translates directly to .mildew.lottery-ticket.

It would be more like .mold.ticket

Re: .localhost Domains

#166
This feels like more work than necessary, I'm not seeing an advantage. Ideally any kind of dev setup should be as contained/localized as possible, but if I'm having to modify OS components, then that feels like sprawl. Or, it's like /etc/hosts but with extra steps.

Re: .localhost Domains

#167

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…

It's easy to be tricked into thinking macOS supports it, because both Chrome and Curl support it. However, ping does not, nor do more basic tools like Python's request library (and I presume urllib as well).

Re: .localhost Domains

#168
My preference for local TLDs is just .x because it takes less time to enter on mobile devices. An example is www.x or video.x.

Yes, it does require a cert for TLS and that cert will not be trusted by default. I have found that with OpenSSL and a proper script you can spin up a cert chain on the fly and you can make these certs trusted in both Windows and Linux with an additional script. A script cannot make for trusted certs in Safari on OSX though.

I figured all this out in a prior personal app. In my current web server app I just don’t bother with trust. I create the certs and just let the browser display its page about high risk with the accept the consequences button. It’s a one time choice.

Re: .localhost Domains

#169
post #165
post #154

Earlier quoted context omitted.

> I have to say, .home.arpa doesn't exactly roll of the tongue like .internal. In my native language (Finnish) it's even worse, or better, depending on personal preference - it translates directly to .mildew.lottery-ticket.

It would be more like .mold.ticket

Thanks, I always mix up mold and mildew. However, "arpa" is specifically a lottery ticket, whereas there are tickets for concerts, tickets to ride, tickets in Jira etc...

Re: .localhost Domains

#170

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-…

But is this an unconstraint root, or does it use name constraints to limit it to localhost domains/IPs? And how does it handle/store the private key associated with that root?
Post reply on HN