Special-use domain 'home.arpa.' (2018)

Original Article ↗ Hacker News Discussion ↗

Engineers are weighing the benefits of the IETF’s special-use `home.arpa` domain for home networks against long-standing ad hoc choices like `.lan`, `.local`, or hijacked public domains such as `home.com`. Key points include how local naming interacts with TLS: whether to pay for a real domain, run a private certificate authority, or accept browser warnings, and how hard it is to make this work safely for guest devices and IoT gear. The debate also touches on standards efforts like reserving `.internal`, conflicts caused by TLDs such as `.dev` and `.zip`, and the broader need for a first-class, secure way to address private services without undermining public PKI.

Use of home.arpa and Alternatives

  • Several commenters already use home.arpa for home networks and report it “just works,” though some regret adding many subdomains (e.g., iot.home.arpa, services.home.arpa) due to complexity.
  • Others find home.arpa “correct but ugly” and prefer shorter or familiar internal names like .lan, .home, .internal, or hijacking public domains (e.g., home.com on the LAN).
  • Clarification that home.arpa is mainly a standardized default for consumer routers, not a requirement for people who already control a real domain.

Certificates, TLS, and Local CAs

  • Major friction point: you can’t get public CA certificates for home.arpa or other non-public TLDs.
  • Options discussed:
    • Use a real domain (e.g., *.example.com) and wildcard certificates (often via ACME/Let’s Encrypt) for internal services.
    • Run a private CA and install its root on devices; tools and guides are referenced.
  • Strong pushback on asking guests to install a private root CA, since it could enable HTTPS interception for any site they visit on that network.
  • Name Constraints (RFC 5280) are suggested to limit a private CA to certain domains/IP ranges, though client support is described as “spotty.”

HTTP vs HTTPS on Local Networks

  • Some argue HTTPS on LAN is essential for defense-in-depth: prevents credential snooping on WiFi/public networks and avoids leaking passwords when devices fall back to cellular.
  • Others say their threat model doesn’t include LAN attackers and that extra complexity isn’t worth it; they accept browser warnings or skip TLS entirely.
  • Frustration with modern browsers’ strong warnings for HTTP/self-signed certs on purely local IPs like 192.168.x.x or abc.local.

Conflicts Around .local and Other Internal TLDs

  • Longstanding deployments using .local for corporate intranets now conflict with mDNS; this causes daily pain and requires configuration tweaks.
  • Kubernetes’ default cluster.local is noted as contrary to the mDNS standard and problematic when accessed externally.
  • Some hope .local will be freed; others say this is infeasible and point to suggested private-use suffixes like .lan, .internal, etc.

ICANN, Reserved Strings, and Domain Economics

  • .home, .corp, and .mail are on ICANN’s “high risk” list and are not expected to become gTLDs; some therefore use them internally.
  • ICANN is progressing a proposal to reserve .internal for private use.
  • Complaints that ICANN allowed .dev and .zip, breaking expectations and causing conflicts and HSTS-forced HTTPS.
  • Discussion of cheap novelty TLDs for home use vs unpredictable price hikes; some prefer paying slightly more for stable .com/.net and multi‑year registrations.