FINAL VERSION SUBMITTED (IF RATIFIED)
The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote.
FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC
The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.
DRAFT SUBMITTED FOR DISCUSSION
The first draft submitted will be placed here before the call for comments begins. The Draft should be preceded by the name of the person submitting the draft and the date/time. If, during the discussion, the draft is revised, the older version(S) should be left in place and the new version along with a header line identifying the drafter and date/time should be placed above the older version(s), separated by a Horizontal Rule (available + Insert More Content control).
Draft submitted by Eduardo and Satish
ALAC strongly supports reserving the domain name .internal for private use. It fulfills all the criteria suggested for private-use domains by Sec 4.1 of SAC113, and is among the strings mentioned in SAC113 as private-use labels.
This should address a critical and longstanding challenge within network management domains. This recommendation is predicated on the need for standardized, non-public domain names that mitigate the risk of collision with future ICANN-delegated namespaces, thereby ensuring the integrity and isolation of internal network resources. The rationale for this recommendation is grounded in several key observations:
Networks, from large corporate entities to small enterprises and personal home setups, necessitate a segregated domain space for hosting internal resources not intended for external internet access. The current practice of employing arbitrary strings for such purposes harbors the potential for namespace conflicts should ICANN allocate identical strings in future delegations, compromising the private nature of these domains.
The existing RFC 2606 (“Reserved Top Level DNS Names”), which reserves a quartet of namespaces for specific testing (.testing), example (.example), invalid (.invalid), and loopback (.localhost) scenarios, conspicuously lacks a provision for a domain dedicated to private use. This omission is further underscored by the expiration of a draft RFC[1] proposing using two-letter codes for private domains. This measure failed to materialize into a formal standard.
Historically, the .local TLD emerged as a de facto standard for private network use, propelled by its adoption among industry giants like Microsoft. However, the advent of Multicast DNS standards (RFC 6762) necessitated the reservation[2] of .local for specific multicast DNS functions, thereby vacating its informal role as a private-use domain.
RFC 6762's Appendix G, while advising against the use of unregistered TLDs, acknowledges the pragmatic use of specific domains (.intranet, .internal, .private, .corp, .home, .lan) within private networks to circumvent the issues associated with .local. This acknowledgment, however, does not translate into a formal endorsement or reservation of these namespaces for private use.
The prevailing expectation for networks to register public domain names for internal use is fraught with practical and logistical challenges, not least the absence of a guaranteed, conflict-free namespace for private network applications.
The utilization of .internal by established corporations such as Google[3] and Amazon[4] underscores the domain's viability and industry acceptance as a private-use TLD, reinforcing the case for its formal reservation by ICANN.
In light of these considerations, ALAC's support for the reservation of .internal as a dedicated domain for private networks is not only a response to a technical and administrative necessity but also a forward-looking measure to ensure the stability, security, and scalability of network infrastructures in an increasingly interconnected digital landscape. This recommendation aligns with the broader objective of maintaining a coherent, conflict-free global namespace, thereby safeguarding the operational integrity of both public and private network domains.
[1] https://datatracker.ietf.org/doc/html/draft-dnsop-private-use-tld#page-8
[2] https://en.wikipedia.org/wiki/.local
[3] https://cloud.google.com/compute/docs/internal-dns
[4] https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html
Hadia Elminiawi 21.Feb. 2024 at12:20 UTC
I suggest to add a few lines about SAC113 advisory, this is because the public comment is asking if the advice/criteria provided by SAC113 was followed. I propose to add the following points from SAC113 advisory
Additionally, it is worth noting that SAC113 advisory on private use TLDs includes a compilation of some widely recognized private use TLDs., along with their query volumes to two root server identifiers. In this regard ".internal" ranks second in the number of queries to the mentioned root servers. Furthermore, the advisory offers a non comprehensive list of historical and ongoing proposals for private use TLDs, among which is the proposed use of the string ".internal" for internal use.
