.INTERNAL is now reserved for private-use applications

Original Article ↗ Hacker News Discussion ↗

Purpose of .internal

  • ICANN has permanently reserved .internal from the public DNS root for private-use naming, analogous to private IP ranges (e.g., RFC1918).
  • No one will ever be able to register .internal on the public Internet, so organizations can safely use names like service.internal without future collisions.
  • This is partly a reaction to past surprises where pseudo‑TLDs later became real (e.g., .dev), breaking internal setups.

Relation to Other Special or “Private” TLDs

  • .local is reserved by IETF RFC 6762 for mDNS/Bonjour, not general internal DNS; using it for other purposes conflicts with mDNS and can break systems.
  • .home.arpa is an IETF‑reserved home-network domain, but some find it too long/ugly versus very short TLDs like .l or .lan.
  • Other reserved TLDs (.example, .invalid, .test, .localhost) have more specialized purposes; .internal fills a generic “private namespace” gap.
  • There is also .ALT (RFC 9476) for non-DNS “alt roots”; some see it as overlapping with a proposed .pseudo, but use cases remain debated.

Private TLD vs Public Domain for Internal Services

  • Pro‑.internal:

    • Makes “invalid states unrepresentable”: you cannot accidentally expose .internal to the public root, reducing misconfiguration and data leakage.
    • Acts as a clear signal that something must remain private; helps audits and tooling detect unintended egress.
    • Useful when buying/renting a public domain is undesirable or impossible, or when you don’t trust long‑term control of a rented domain.

  • Pro‑public domain (e.g., internal.example.com):

    • Easier TLS: can use public CAs (Let’s Encrypt, ACME DNS) instead of running a private CA.
    • Works seamlessly with BYOD, contractors, VMs/containers, phones, etc. that don’t trust internal CAs.
    • Keeps the option to expose services later without renaming or re‑certifying.
    • Avoids complex private DNS and split-horizon setups that many small orgs struggle with.

TLS, CAs, and Security Trade‑offs

  • .internal cannot use public CAs by design; X.509 trust breaks if multiple organizations can get certs for the same name, so a private CA is required.
  • Many note operational pain: distributing CA roots to all clients (especially mobile), inconsistent trust stores (OS vs browser vs Java), and managing an internal PKI.
  • Others argue “encrypt everything” is still important: LANs and “trusted” VPCs are frequently compromised; zero‑trust models treat internal networks as hostile.
  • Use of public domains exposes names via certificate transparency logs; critics see this as information leakage, supporters call it an acceptable trade‑off.

Operational and Usability Concerns

  • Cookie/storage collisions and name clashes across organizations are possible with shared .internal names, just as with RFC1918 IPs; mitigations include longer, org‑scoped names (e.g., service.company.internal).
  • Browsers currently treat unknown TLDs as search terms; some want special handling so foo.internal behaves more like localhost.
  • Many home/SMB network setups still lack good DHCP+DNS integration; reserved internal TLDs could simplify this if consumer routers used them consistently.