.localhost Domains

Original Article ↗ Hacker News Discussion ↗

Choosing a “local” TLD (.localhost, .local, .test, .internal, etc.)

  • Many commenters like *.localhost for dev: it’s reserved, won’t collide on the public Internet, and in many systems/browsers is hard‑wired to loopback.
  • Several warn against .local: it’s reserved for mDNS/Bonjour, can cause slow or flaky resolution, and conflicts with link‑local naming. Still, some report good results when they deliberately use mDNS on their LAN.
  • .test is popular for app testing because it’s reserved, short, and consistently resolved by browsers.
  • .internal has recently been reserved for private use and is recommended by some for non‑loopback “real” internal services. Others point to *.home.arpa for residential networks, but complain it’s clunky and poorly adopted.
  • Some people ignore special TLDs entirely and:
    • Use a real domain or a dedicated second domain for dev/QA.
    • Invent an unused TLD or a fake subdomain of someone else’s domain (seen as risky but often works in practice).

HTTPS, certificates, and “secure contexts”

  • There’s strong frustration that HTTPS on LAN is hard: you either run your own CA, install root certs everywhere, or expose internal names via public CAs/CT logs.
  • Tools like Caddy, mkcert, Smallstep, and similar wrappers (e.g. Localias) are used to automate local CAs and per‑service certs.
  • Some argue HTTPS on LAN is “basically useless”; others counter that:
    • Browsers gate powerful APIs and HTTP/2 behind HTTPS.
    • Admin interfaces on Wi‑Fi and public networks absolutely benefit from TLS.
  • Browsers treat localhost (and often *.localhost) as a secure context even over HTTP, relaxing some requirements and making it attractive for frontend development.

DNS, OS, and browser quirks

  • Behavior of *.localhost is inconsistent: many Linux systems (systemd‑resolved, NSS myhostname) and some DNS setups resolve it to 127.0.0.1/::1 automatically; macOS support is reported as patchy and network‑dependent.
  • Safari may search for .localhost unless a trailing slash or scheme is added; Chromium often treats .localhost specially and may bypass system DNS.
  • Some prefer dnsmasq/unbound or custom DNS servers to wildcard *.localhost (or other TLDs) across the LAN instead of per‑host /etc/hosts hacks.

Reverse proxies, containers, and multi‑service dev

  • Common pattern: run a reverse proxy (Caddy, nginx, Traefik) on loopback and route based on Host header so each app gets myapp.localhost instead of unique ports.
  • This mirrors production (virtual hosts, TLS, subdomains) and simplifies multi‑service or Docker‑compose setups.
  • Alternatives include:
    • Binding different services to distinct loopback IPs within 127.0.0.0/8 or another reserved block.
    • Using container orchestrators or tools (OrbStack, Traefik configs, custom Go DNS proxies) that auto‑assign hostnames to containers.

Overall sentiment

  • There’s broad agreement that .local for non‑mDNS use is a bad idea and that .localhost/.test/.internal or real domains are safer.
  • Many see the current landscape of LAN HTTPS and local naming as unnecessarily complex for such a common use case.