Proposed top-level domain string for private use: ".internal"

Original Article ↗ Hacker News Discussion ↗

ICANN’s plan to reserve the “.internal” top‑level domain for private networks aims to give organizations a guaranteed-never-public suffix for internal DNS, avoiding past problems where unofficial choices like “.dev” or “.local” later conflicted with public use or mDNS. Commenters weigh the benefits of a clear, standardized private TLD against concerns over its length and limited TLS support (since public certificate authorities won’t issue certs for it), with many arguing that using subdomains of real, owned domains plus existing reserved names like “home.arpa” remains more practical in many setups.

Existing special-use domains & conflicts

  • Thread reviews current reserved/special-use domains: .example, .invalid, .localhost, .test, .local, .onion, home.arpa.
  • .localhost has standardized loopback behavior; some resolvers implement this, others require local DNS config.
  • .local is widely criticized for clashing with mDNS/Bonjour and zeroconf; many links and war stories about broken service discovery and legacy AD setups.
  • .corp, .home, .mail processing has been “deferred indefinitely” by ICANN, which is seen as weaker than explicit reservation.

Pros and cons of .internal

  • ICANN/IANA propose .internal as a private-use TLD that will “never be delegated.”
  • Supporters like the clarity, broader scope than “home,” and the safety of non-delegation (no later .dev-style surprise).
  • Critics find it too long and awkward to type, especially on TVs/IoT UIs; many prefer short options like .lan, .intra, or even .d.
  • Some worry about confusion with .int and potential lookalike/phishing patterns like foo.int/ernal.
  • There is skepticism that ICANN won’t later monetize alternative short strings; general distrust due to .dev, .sucks, and prior controversies.

Internal DNS design patterns

  • Strong advice from several commenters: use a domain you actually control (e.g., internal.example.com) rather than invented TLDs.
  • Others highlight issues with that approach: DNSSEC disclosure of internal names, split-DNS complexity, outages, and user confusion over what is internal vs external.
  • Many legacy deployments used .local or .dev internally and later suffered when those became special or public.
  • Some avoid DNS entirely for small/home setups using /etc/hosts or local DNS fed from hosts files.

TLS and certificate issues

  • .internal domains cannot get public CA certificates; organizations would need private CAs or self-signed certs.
  • Several point out usability and security problems when devices roam between networks and trust multiple private CAs, enabling collisions on the same hostname.
  • Ideas raised: better browser support for Name Constraints, internal-only domain registration compatible with Let’s Encrypt (via DNS-01 only), and formalizing patterns for HTTPS on local networks.

Alternatives and usability

  • home.arpa is already standardized for residential use; some like its clarity, others find it long and awkward.
  • Common ad‑hoc choices mentioned: .lan, .lab, .home, .localnet, .d, short hostnames plus search domains, or router-specific domains like fritz.box.
  • One camp argues any special TLD will eventually be misused or co‑opted; therefore, “just use a real domain” remains a recurring recommendation.