New gTLD Application for .lan

Original Article ↗ Hacker News Discussion ↗

A new application to make “.lan” a public internet top-level domain is alarming many network admins, because “.lan” has long been used informally by home and small‑business routers for internal device names. Commenters warn this could create dangerous name collisions and traffic leaks, especially for plaintext services, and argue that ICANN should instead reserve .lan for private use or rely on already designated domains like `home.arpa` or `.internal`. Others suggest practical mitigations, such as blocking .lan at resolvers or migrating to a registered domain for internal networks, while criticizing the broader expansion of gTLDs as driven more by revenue than by technical need.

Background: .lan and existing usage

  • Many home and SMB routers (e.g., OpenWrt-based, Ubiquiti, others) default to assigning hostname.lan for LAN devices.
  • Users often rely on this for convenience and sometimes send plaintext traffic to these names.
  • Some setups (dnsmasq, Pi-hole, RPZ lists) already treat .lan as local-only and block forwarding to public resolvers.

Security and privacy concerns

  • Making .lan a public gTLD risks:
    • DNS “leakage” of internal hostnames to the internet.
    • Traffic meant for internal services reaching arbitrary external servers, enabling phishing, credential capture, or misrouting of sensitive data.
  • Past real-world collisions (e.g., .box vs fritz.box) are cited as cautionary examples.
  • Some argue this mirrors the problem of using unassigned public IP ranges on private networks.

Alternatives for private namespaces

  • RFC 8375 defines home.arpa for home networks; critics dislike its length, two-level structure, and obscure “arpa” reference.
  • .internal has been reserved by ICANN (since 2024) for internal use and is suggested as a safer choice.
  • .local is reserved for mDNS and considered inappropriate for things like Active Directory.
  • .alt (RFC 9476), reserved ccTLD-like codes (.qm–.qz, .xa–.xz), and single-letter fake TLDs are mentioned, but seen as unintuitive.
  • Many prefer using a registered domain or subdomain (e.g., internal.company.com) for internal DNS, benefiting from public TLS certs.

ICANN process, objections, and governance

  • New gTLDs undergo a Name Collision Risk Management Framework; high-risk strings (like .corp, .home, .mail) were previously “indefinitely deferred.”
  • Some hope .lan will be classified similarly; others note leakage metrics may be skewed because many routers already block .lan upstream.
  • Formal objections are limited (string confusion, legal rights, “limited public interest,” and community objections) and require significant fees, making grassroots opposition hard.
  • Debate over responsibility:
    • One side: ICANN/IANA “DNS police” that should have reserved .lan long ago.
    • Other side: users and vendors knowingly gambled by using unreserved names.

Views on gTLD expansion and .dev precedent

  • Many see gTLD proliferation as primarily revenue-driven, increasing phishing/scam surface with little end-user value.
  • The .dev case is frequently cited: it was widely used for local development; Google’s application language suggested protection, but it was then sold commercially, breaking tools and setups.

Practical reactions and advice

  • Some plan to keep .lan but block it at resolvers, making public .lan domains effectively unreachable.
  • Others are migrating to .internal, home.arpa, or owned domains, or adding search domains so users still type short hostnames.
  • General sentiment: applying .lan as a public gTLD is unnecessary, confusing (given “Local Area Network”), and likely harmful, though a minority emphasize that using unreserved TLDs was always a risk.