[HN Gopher] .localhost Domains
___________________________________________________________________
.localhost Domains
Author : todsacerdoti
Score : 187 points
Date : 2025-04-10 14:19 UTC (8 hours ago)
(HTM) web link (inclouds.space)
(TXT) w3m dump (inclouds.space)
| chuckwnelson wrote:
| 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/
| mohsen1 wrote:
| 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.
| EGreg wrote:
| Actually, MacOS gives your computer a .local domain on DHCP and
| Bonjour usually
| defraudbah wrote:
| if you add your CA to the list of trusted certificate,
| everything will be fine. I do not recommend using custom
| certificates and would stick to http, unless you really know
| what you are doing
| jeroenhd wrote:
| I use .local all the time and it works just fine. For TLS I use
| my existing personal CA, but HTTP links don't cause issues for
| me.
|
| That said, I do use mDNS/Bonjour to resolve .local addresses
| (which is probably what breaks .local if you're using it as a
| placeholder for a real domain). Using .local as a imaginary LAN
| domain is a terrible idea. These days, .internal is reserved
| for that.
| rcarmo wrote:
| .local is mDNS/Rendezvous/Bonjour territory. In some cases it
| takes longer to resolve because your machine will multicast a
| query for the owner of the name.
|
| I use it extensively on my LAN with great success, but I have
| Macs and Linux machines with Avahi. People who don't shouldn't
| mess with it...
| zamadatix wrote:
| The reason is .local is a special case TLD for link-local
| networking with name resolution through things like mdns, by
| trying to hijack it for other use things might not go as you
| intend. Alternatively, .localhost is just a reserved TLD so it
| has no other usage to check.
|
| https://en.wikipedia.org/wiki/.local
|
| https://en.wikipedia.org/wiki/.localhost
| Pxtl wrote:
| 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.
| Spooky23 wrote:
| It's actually gotten worse, you need to run a CA or use a
| public domain where it's easy to get your internal naming
| schemes in a transparency log.
| jeroenhd wrote:
| The easy workaround I've seen companies use for that is by
| using a basic wildcard certificate (*.local.mydomain.biz).
| jeroenhd wrote:
| _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.
| mohsen1 wrote:
| Some more modern browser APIs only work in HTTPS. That's
| why I had to do it.
| 1wheel wrote:
| Browsers won't use http2 unless https is on -- chrome only
| allows six concurrent requests to the same domain if you're
| not using https!
| Pxtl wrote:
| > 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?
| justin_oaks wrote:
| I recommend using the .test TLD.
|
| * It's reserved so it's not going to be used on the public
| internet.
|
| * It is shorter than .local or .localhost.
|
| * On QWERTY keyboards "test" is easy to type with one hand.
| mjevans wrote:
| Once again, .local should _never_ have been assigned to any
| organization. Just like .lan should also be reserved like the
| private IP blocks.
| XorNot wrote:
| Don't we have ".internal" for that?
| jeroenhd wrote:
| The TLD hasn't been registered, but it has been added to the
| list of reserved names so effectively that's the domain you
| should use if you don't want to use real names.
|
| .local also works fine, of course, if you enable mDNS and
| don't try to use normal DNS.
| WorldMaker wrote:
| .local _wasn 't_ assigned to an organization, it was assigned
| to mDNS: multicast DNS. mDNS is the ask everyone on the local
| network if they like to be called that name which used to be
| better known under Apple's brand/trademark Bonjour, but now is
| a true standard.
| mjevans wrote:
| 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 )
| WorldMaker wrote:
| 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 with it, but don't share your concern.
| mjevans wrote:
| 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.
| defraudbah wrote:
| People used localtest.me back in the days :)
|
| https://weblogs.asp.net/owscott/introducing-testing-domain-l...
| EGreg wrote:
| Wow! Today I learned that you can have subdomains of localhost.
| Never realized it!
| jeroenhd wrote:
| .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 address and is reserved for
| such use". In other words, your server may be binding to ::1
| but your browser may be resolving 127.0.0.1. I'm sure later
| RFCs rectify the lack of IPv6 addressing, but I wouldn't assume
| everyone has updated to support those.
|
| Another neat trick to combine with .localhost is using
| 127.0.0.0/8. There's nothing preventing you from binding
| server/containers to 127.0.0.2, 127.1.2.3, or 127.254.254.1.
| Quite useful if you want to run multiple different web servers
| together.
| EGreg wrote:
| But is "foo.localhost" a valid domain name, for cookies and
| such?
| jeroenhd wrote:
| The RFC treats .localhost as a full TLD. I believe Windows
| does as well, as does Ubuntu (using default systemd-
| resolved), but macOS doesn't seem to resolve .localhost by
| default, necessitating the host file trickery.
|
| Of course, in the early internet, the difference between a
| TLD and a host name weren't quite as clear as they are
| right now.
| EGreg wrote:
| We still need the Public Suffix List because of how
| inconsistent it was
| sebazzz wrote:
| > I believe Windows does as well
|
| I cannot ping xyz.localhost because it doesn't resolve
| it.
| andrewstuart2 wrote:
| 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 (and would simply
| go to that address ignoring whatever was in /etc/hosts or DNS,
| again IIRC). It's been a while, though, so that behavior might
| have changed.
|
| [0] https://datatracker.ietf.org/doc/rfc2606/
| jeroenhd wrote:
| .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.
| numbsafari wrote:
| This is what I've done for years: doing app development using
| the .test TLD, and .internal for, well, internal services
| that are more like "production IT".
|
| I've had nothing but trouble with .local and .localhost.
| Specifically, .local is intended for other purposes
| (multicast DNS) and .localhost has a nasty habit of turning
| into just "localhost" and in some cases, resolvers don't like
| to allow that to point to anything other than 127.0.0.1.
|
| More recently, I've stuck to following the advice of RFC 6762
| and use an actual registered TLD for internal use, and then
| sub-domain from there. I don't use my "production" TLD, but
| some other, unrelated TLD. For example, if my company is
| named FOO and our corporate homepage is at foo.com, I'll have
| a separate TLD like bar.com that I'll use for app development
| (and sub-domain as dev.bar.com, qa.bar.com, and maybe
| otherqa.bar.com as needed for different environments). That
| helps avoid any weirdness around .localhost, works well in
| larger dev/qa environments that aren't running on 127.0.0.1,
| and allows me to do things like have an internal CA for TLS
| instead of using self-signed certs with all of their UX
| warts.
|
| For "local network" stuff, I stick to ".internal" because
| that's now what IANA recommends. But I would distinguish
| between how I use ".internal" to mean "things on my local
| network" from "this is where my team deploys our QA
| environment", because we likely aren't on the same network as
| where that QA environment is located and my ".internal" might
| overlap with your ".internal", but the QA environment is
| shared.
| lima wrote:
| 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.
| lima wrote:
| On my Linux machine with systemd-resolved, this even works out
| the box: $ resolvectl query foo.localhost
| foo.localhost: 127.0.0.1 -- link: lo
| ::1 -- link: lo
|
| Another benefit is being able to block CSRF using the reverse
| proxy.
| jchw wrote:
| Yeah, I've been using localhost domains on Linux for a while.
| Even on machines without systemd-resolved, you can still
| usually use them if you have the myhostname module in your NSS
| DNS module list.
|
| https://www.man7.org/linux/man-pages/man8/libnss_myhostname....
|
| (There are lots of other useful NSS modules, too. I like the
| libvirt ones. Not sure if there's any good way to use these
| alongside systemd-resolved.)
| aib wrote:
| I ended up writing a similar plugin[1] after searching in
| vain for a way to add temporary DNS entries.
|
| The ability to add host entries via an environment variable
| turned out to be more useful than I'd expected, though mostly
| for MITM(proxy) and troubleshooting.
|
| 1: https://github.com/aib/nss-userhosts
| accrual wrote:
| Neat setup! I do something similar on OpenBSD. I have a CSV file
| that maps IP, MAC address, and hostname for various devices on my
| LAN. A shell script reads the file and creates a matching hosts
| file, dhcpd config, and unbound config, then restarts dhcpd and
| unbound (caching DNS server).
|
| Whenever a host requests a DHCP lease it receives its assigned IP
| which matches the unbound record, then I can always access it by
| hostname.
| radel wrote:
| I think you don't really need the /etc/hosts entry, I use this
| since google started using .dev domains and switched to using
| .localhost for everything local.
|
| Never needed the entry
| oulipo wrote:
| and you're still setting up a proxy for the port forwarding?
| hardaker wrote:
| You might check out .internal instead which was recently approved
| [1] for local use.
|
| [1]: https://en.wikipedia.org/wiki/.internal
| codetrotter wrote:
| In that case I would prefer naming as
| <virtual>.<physical-host>.internal
|
| So for example phpbb.mtndew.internal
|
| And I'd probably still add phpbb.localhost
|
| To /etc/hosts on that host like OP does
| nodesocket wrote:
| I wrote a super basic DNS server in go (mostly fun and go
| practice) which allows you to specify hosts and ips in a json
| config file. This eliminates the need for editing your
| /etc/hosts file. If it matches a host in the json config file
| it returns that ip, else uses Cloudflare public DNS resolver
| as a fallback. Please; easy on my go code :-). I am a total
| beginner with go.
|
| https://github.com/nodesocket/godns
| GrumpyYoungMan wrote:
| 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.
| Mountain_Skies wrote:
| It's ugly and clunky, which is why after seven years it's had
| very little adoption. Home users aren't network engineers so
| these things actually do matter even if it seems silly in a
| technical sense.
| styfle wrote:
| Why use that over *.localhost which has been available since
| 1999 (introduced in RFC 2606)
| bravetraveler wrote:
| From RFC 2606: The ".localhost" TLD has
| traditionally been statically defined in host DNS
| implementations as having an A record pointing to the
| loop back IP address and is reserved for such use
|
| The RFC 8375 suggestion _(*.home.arpa)_ allows for more
| than a single host in the domain. If not in name /feeling,
| but the strictest readings _[and adherence]_ too.
| johnmaguire wrote:
| 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: htt
| ps://www.reddit.com/r/MacOS/comments/1bu62do/homearpa_is_...
| candiddevmike wrote:
| 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.
| MaKey wrote:
| 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.
| jwilk wrote:
| 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._
| alexvitkov wrote:
| 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 :^)
| tepmoc wrote:
| eh, you can just add search domain via dhcp or static
| configuration and just type out http://mything/ no need to
| enter whole domain unless you need todo ssl
| nsteel wrote:
| Isn't just typing the slash at the end enough to avoid it
| searching? e.g. mything/
| eddyg wrote:
| _.home_ , _.corp_ and _.mail_ are on ICANN's "high risk" list
| so won't ever be gTLDs, so they are also good (short) options.
|
| Ref: https://www.icann.org/en/board-activities-and-
| meetings/mater...
| _def wrote:
| I recently tried to use the dnsmasq method mentioned at the very
| end but had some issues with fallthrough, as most of my dns
| traffic went trough my dev setup then first, which I didn't want.
| In the end I configured a "real" domain and let it point to
| 127.0.0.1, because I need arbitrary wildcard subdomains.. but I'm
| still not very happy with it because it feels like an unecessary
| dependency.
| delduca wrote:
| I do the same at work (on premise machines on a private LAN).
| thorvaldsson wrote:
| In my case I just setup a subdomain 'local.<domain>' to my
| personal domain and had Let's Encrypt create valid certificates
| for it via Traefik.
|
| Each service is then exposed via '<service>.local.<domain>'.
|
| This has been working flawlessly for me for some time.
| jFriedensreich wrote:
| Chrome and i think Firefox resolve all <name>.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 <containername>.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.
| riffic wrote:
| > I then run and configure Caddy to redirect traffic from
| 127.0.0.1 to the right port for the domain.
|
| That's not _redirection_ per se, a word that 's needlessly
| overloaded to the point of confusion. It's a smart use of a
| _reverse proxy._
|
| It would be nice if you all reserved the word "redirect" for
| something like HTTP 3xx behavior.
| vlod wrote:
| 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
| jeroenhd wrote:
| 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.
| vlod wrote:
| Thanks. This is the reason I wanted rather then convenience
| of not typing a port number (which I'd use a bookmark for, so
| I really don't care)
| ghoshbishakh wrote:
| 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
| gwd wrote:
| It's `myapp.localhost` (without the port number). It's more
| useful because it's easier to allocate and remember a unique
| name than a unique port number.
| tgpc wrote:
| maybe you're running a reverse proxy? it can direct you
| differently depending on how you refer to it
| csciutto wrote:
| The comparison is `myapp.localhost` vs `localhost:3000`. This
| is especially useful when you have web servers permanently
| running on your computer on ports, not just for momentaneous
| local development.
| mrweasel wrote:
| Maybe you have a stack of applications that needs to
| communicate. Seeing db.localhost is a little easier to read
| that db:3360, but especially if you have multiple web
| applications. It's easier to read sso.localhost, api.localhost,
| and www.localhost.
|
| They also show having the webserver to the TLS, that might be
| helpful.
| cyral wrote:
| Note the use of the Caddy webserver (you could also use nginx
| or whatever), which proxies to the port, so it's just
| myapp.localhost. I like this because it mirrors our production
| site. We can have subdomain.myapp.localhost and
| subdomain.myapp.com so links and everything work properly in
| both environments (assuming you have an env variable for the
| base domain)
| oulipo wrote:
| Could there be a way to setup the Caddy server dynamically
| using eg direnv so that it's only launched when I'm in my dev
| folder?
| AStonesThrow wrote:
| 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...
| mrweasel wrote:
| 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.
| donatj wrote:
| 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
| oulipo wrote:
| Can you expand on this? you redirect *.local.example.com to
| 127.0.0.1, and then how do you setup the local machine so that
| eg myservice.local.example.com hits the correct port? I guess
| you still need a proxy somewhere? or you specify eg
| myservice.local.example.com:3000 ?
| donatj wrote:
| It's not a redirect. It's an actual A record on the domain
| for local.example.com -> 127.0.0.1
|
| Then we just have an entry for local.example.com in our
| vhosts and bam everything works as expected. No need to mess
| with /etc/hosts
| WhyNotHugo wrote:
| 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 this; I always thought that localhost was
| a highly standard thing covered in the RFC long long ago...
| apparently it isn't, and macOS still doesn't handle this TLD.
| oulipo wrote:
| 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
| Shywim wrote:
| Not for me, MacOS 15.4: $ ping
| hello.localhost ping: cannot resolve hello.localhost:
| Unknown host
| fimdomeio wrote:
| 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
| tedunangst wrote:
| That's because your DNS server sends back 127.0.0.1. The
| query isn't resolved locally.
| parasti wrote:
| I am doing this on macOS with no problem.
| jwilk wrote:
| > Any subdomain of .localhost works out-of-the-box on Linux
|
| No, not here.
| jchw wrote:
| 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.
| nhance wrote:
| As a reminder, lacolhost.com and all subdomains will forever
| resolve to localhost (well for as long as I'm around at least)
| koolba wrote:
| > As a reminder, lacolhost.com ...
|
| I'm assuming that typo is intentional?
| jeroenhd wrote:
| > (well for as long as I'm around at least)
|
| Rather big caveat IMO. As a side note, your domain doesn't seem
| to have an AAAA record (which [.]localhost binds to by default
| on most of my machines, at least).
| bootcat wrote:
| wow this is hitting hacker news front page ? if we can change the
| hosts file - I want to propose you can have any domain name for
| local services.
| whalesalad wrote:
| I have a public domain that resolves to a static lease in my
| internal network, which is running nginx proxy manager.
|
| When I add a new site to my local setup, I just define a CNAME in
| Cloudflare and add an entry in Nginx proxy manager. It handles
| SSL via wildcard cert.
| jbverschoor wrote:
| Orbstack does all that pretty automatically. It also understands
| project structure / compose.
|
| https://service.project.orb/
| Tokumei-no-hito wrote:
| broken link
| zsoltkacsandi wrote:
| It was an example how OrbStack puts together the domain.
| jbverschoor wrote:
| Docs at https://docs.orbstack.dev/docker/domains
|
| Forgot to add .local I see
| VikingCoder wrote:
| Tailscale is another neat way. You can have ephemeral nodes. I
| want to learn how to do it with Docker, but apparently it's not
| too bad.
| peterldowns wrote:
| 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 real phone. It also
| syncs your /etc/hosts so you never need to edit it manually.
|
| Check it out and let me know what you think! (Free, MIT-licensed,
| single-binary install)
|
| Basically, it wraps up the instructions in this blogpost and
| makes everything easy for you and your team.
|
| https://github.com/peterldowns/localias
| CodesInChaos wrote:
| 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?)
| sangeeth96 wrote:
| 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-y...
| lxgr wrote:
| > Install the local root certificate to the system's trust
| stores
|
| I really wish there was a safer way to do this, i.e. a way
| to tag a trusted CA as "valid for localhost use only". The
| article mentions this in passing
|
| > The sudo version of the above command with the -d flag
| also works but it adds the certificate to the System
| keychain for all users. I like to limit privileges wherever
| possible.
|
| But this is a clear case of https://xkcd.com/1200/.
|
| Maybe this could be done using the name constraint
| extension marked as critical?
| worewood wrote:
| I think an alternative to local root certs would be to use a
| public cert + dnsmasq on your LAN to resolve the requests to
| a local address.
| silvanocerza wrote:
| I went a different way for my internal network, I use tv.it for
| my server and rt.it for the router. All two characters .it
| domains are non registrable so you risk no clash, the only
| existing one is q8.it.
|
| I have a more in depth write up here:
| https://www.silvanocerza.com/posts/my-home-network-setup/
| chippiewill wrote:
| For internal networks the `internal` tld is reserved
| silvanocerza wrote:
| I know.
|
| Though I wanted a short URL, that's why I used .it any way.
| octagons wrote:
| 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 recommend the use of the internal. zone for any
| such setup, as others have commented. This article provides some
| good reasons why (at least for .local) you should aim to use a
| standards-compliant internal zone:
| https://community.veeam.com/blogs-and-podcasts-57/why-using-...
| hobo_mark wrote:
| 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?
| thot_experiment wrote:
| I alias home.com to my local house stuff. I don't really
| understand why anyone thinks it's a bad idea either.
| matthewaveryusa wrote:
| It's not a terrible idea. On a large scale it can lead to
| the corp.com issue:
|
| https://krebsonsecurity.com/2020/02/dangerous-domain-corp-
| co...
|
| Honestly for USD5/year why don't you just buy yourself a
| domain and never have to deal with the problem?
| szszrk wrote:
| For home it's not that bad, but there could be conflicts at
| some point. Your clients will send data to the Internet
| unknowingly when dns is missconfigured.
|
| It's better to use domain you control.
|
| I'm a fan of buying cheapest to extend (like .ovh, great
| value) and use real Let's Encrypt (via dns challenge) to
| register any subdomain/wildcard. So that any device will have
| "green padlock" for totally local service.
| octagons wrote:
| To be clear, I didn't register anything. I just have a
| configuration that serves records for a zone like
| "artichoke." on my DNS server. Internal hosts are then
| accessible via https://gitlab.artichoke, for example.
| tbyehl wrote:
| What's the argument against using one's own actual domain? In
| these modern times where every device and software wants to
| force HTTPS, being able to get rid of all the browser warnings
| is nice.
| waynesonfire wrote:
| I think this is ideal. You make a great point that even if
| you were to use .internal TLD that is reserved for internal
| use, you wouldn't be able to use letsencrypt to get a SSL
| certificate for it. Not sure if there are other ssl options
| for .internal. But, self-signed is a PITA.
|
| I guess the lesson is to deploy a self-signed root ca in your
| infra early.
| octagons wrote:
| Check out Smallstep's step-ca server [0]. It still requires
| some work, but it allows you to run your own CA and ACME
| server. I have nothing against just hosting records off of
| a subdomain and using LE as mentioned, but I personally
| find it satisfying to host everything myself.
|
| [0] https://smallstep.com/docs/step-ca/
| mholt wrote:
| When using `.localhost` in the Caddyfile, you don't even need the
| `tls internal` line since that's assumed for that TLD.
| pwdisswordfishz wrote:
| Or you could have /etc/hosts resolve them to other addresses in
| the 127.0/8 block.
| subculture wrote:
| When Apple's MobileMe came out I snagged the localhost@me.com
| email address, thinking how clever I was. But because filtering
| tools weren't as good back then I was never able to use it
| because of the truly massive amount of spam and test emails I'd
| get.
| leshokunin wrote:
| Thanks for the laugh. I wonder what test@gmail.com gets hahaha
| isleyaardvark wrote:
| For anyone unaware, the domain 'example.com' is specifically
| reserved for the purpose of testing, so you don't have to
| worry about some rando reading emails sent to
| "test@gmail.com"
| sigil wrote:
| This nginx local dev config snippet is one-and-done:
| # Proxy to a backend server based on the hostname. if (-d
| vhosts/$host) { proxy_pass
| http://unix:vhosts/$host/server.sock; break; }
|
| Your local dev servers must listen on a unix domain socket, and
| you must drop a symlink to them at eg
| /var/lib/nginx/vhosts/inclouds.localhost/server.sock.
|
| Not a single command, and you still have to add hostname
| resolution. But you don't have to programmatically edit config
| files or restart the proxy to stand up a new dev server!
| ku1ik wrote:
| This is neat!
| hn92726819 wrote:
| I'm not that familiar with nginx config. Does this protect
| against path traversal? Ex: host=../../../docker.sock
| sigil wrote:
| nginx validates hostnames per the spec, and to your question
| specifically it rejects requests that would put a slash in
| $host: https://github.com/nginx/nginx/blob/b6e7eb0f5792d7a52d
| 2675ee...
| joey_spaztard wrote:
| 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.
| jrockway wrote:
| 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.
| smjburton wrote:
| 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
| everything is set up.
| shadowpho wrote:
| > 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.
| smjburton wrote:
| 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/.
| qwertox wrote:
| I was on a similar thought process, but this leaves you only
| with the option to set the A record of the public DNS entry to
| 127.0.0.1, if you want to use it on the go.
|
| Though you could register a name like ch.ch and get a wildcard
| certificate for *.ch.ch, and insert local.ch.ch in the hosts
| file and use the certificate in the proxy, that would even work
| on the go.
| whatevaa wrote:
| 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?
| smjburton wrote:
| 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.
| egoisticalgoat wrote:
| If you're already adding a CA to your trust store, you can
| just use caddy! [0] Add their local CA to your store (CA
| cert is valid for 10 years), and it'll generate a new cert
| per local domain every day.
|
| Actually, now that I've linked the docs, it seems they use
| smallstep internally as well haha
|
| [0] https://caddyserver.com/docs/automatic-https#local-
| https
| nine_k wrote:
| 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.
| justin_oaks wrote:
| 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 containers. Things got more
| complicated if I wanted to access an HTTP service both from my
| host machine and from other Docker containers. Instead of
| having your services exposed differently inside a docker
| network and outside of it, you can consistently use the IP and
| Ports you expose/map.
|
| If you're 127.0.0.0/8 addresses then this won't work. The local
| loopback addresses aren't routed to the host computer when sent
| from a Docker container; they're routed to the container. In
| other words, 127.0.0.1 inside Docker means "this container" not
| "this machine".
|
| For that reason I picked some other unused IP block [0] and
| assigned that block to the local loopback interface. Now I use
| those IPs for assigning to my docker containers.
|
| I wouldn't recommend using the RFC 1918 IP blocks since those
| are frequently used in LANs and within Docker itself. You can
| use something like the link-local IP block (169.254.0.0/16)
| which I've never seen used outside of the AWS EC2 metadata
| service. Or you can use the carrier-grade NAT IP block
| (100.64.0.0/16). Or even some IP block that's assigned for
| public use, but is never used, although that can be risky.
|
| I use Debian Bookworm. I can bind 100.64.0.0/16 to my local
| loopback interface by creating a file under
| /etc/network/interfaces.d/ with the following
| auto lo:1 iface lo:1 inet static address
| 100.64.0.1 gateway 100.64.0.0 netmask
| 255.255.0.0
|
| Once that's set up I can expose the port of one Docker
| container at 100.64.0.2:80, another at 100.64.0.3:80, etc.
|
| [0] https://en.wikipedia.org/wiki/Reserved_IP_addresses
| threatofrain wrote:
| How do JS local dev setups use nice names like
| `local.drizzle.studio`?
| Jnr wrote:
| That is an external domain. Javascript on that site connects to
| the locally running drizzle service.
| ipkstef wrote:
| you guys don't just memorize all your local ip's?
| justin_oaks wrote:
| In my day we memorized IPs AND ports. 10.24.67.22:78342 was to
| access our bug tracker and 192.168.240.17:21282 was for our CVS
| repository!
|
| Seriously though, one of the first things I did when I was
| hired as the sysadmin for a small company was to eliminate the
| need for memorizing/bookmarking ip-port combos. I moved
| everything to standard ports and DNS names.
|
| Any services running on the same machine that needed the same
| ports were put behind a reverse proxy with virtual hosts to
| route to the right service. Each IP address was assigned an
| easy-to-remember DNS name. And each service was setup with
| TLS/SSL instead of the bare HTTP they had previously.
| djanowski wrote:
| Recently I started to work on a very simple tool to do this with
| a single command: it'll start all your projects in a given
| directory and expose them via HTTPS on
| https://[project].localhost
|
| No daemons, and the only piece of configuration is adding a file
| to /etc/resolvers: https://github.com/djanowski/hostel
|
| I've been using it for myself so it's lacking documentation and
| features. For example, it expects to run each project using `npm
| run dev`, but I want to add Procfile support.
|
| Hopefully other people find it useful. Contributions very much
| welcome!
| jdprgm wrote:
| I do something similar with Caddy but add dns-sd to broadcast on
| mDNS so i can just hit myapp.local from anywhere on my network
| and don't have to do anything with hosts and it just works. Been
| on my todo list to wrap this into a tiny mac menubar app.
| mmanfrin wrote:
| The comments here all suggesting different arcane and complicated
| stacks of different devops solutions and certificates and
| configurations and services has me somewhat despairing that such
| a _COMMON_ usecase is still so annoyingly obtuse.
___________________________________________________________________
(page generated 2025-04-10 23:01 UTC)