Public Comment

Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.

هذا المحتوى متوفر فقط باللغة (أو اللغات)

  • English

Name: Arnaldo Pirrone
Date: 13 Mar 2024
Other Comments

Considering that:

- The use of .home., .corp., .lan., .private., .intranet., .internal. and other non-delegated TLDs was generally not recommended nor endorsed by any serious organization;

- The wrong common practice, from device manufacturers and network administrators (both professional and amateur), of using a handful among the shortest of these TLDs for local name resolution has been around for a long time with all the issues and risks involved;

- As opposed to what happened with the private IP address blocks, little is known about what has been done throughout history for reserving a TLD string for local name resolution;

- Awareness of the situation led to the formulation of the RFC 8375, establishing for the first time a reserved domain, although the fact that it is strictly associated with HNCP in conjunction with the associative meaning of that name are making it unsuitable for covering the multitude of networking scenarios out there;

- It's plausible to think that the concerns on this matter started growing more and more through the years that followed, with the common though eventually calling out loud for a turnaround.

- The well known consequences of inconsiderate use of unregistered TLDs are thoroughly described in the SSAC report 113 which can be found at this URL,

with special attention to the DNS root servers being flooded with unnecessary queries;

- The recent events that affected the AVM GmbH company, whose domain used as local domain suffix in the default configuration of their home gateway products, was registered from an unrelated party; it goes without saying that home equipment manufacturers are expected to strictly observe the associated BCP and only use the newly proposed string and its subdomains instead of using whatever comes to their mind;

- A proper way to resolve local hostnames shall be granted for free to everybody, without disparity, without being subject to service disruption in the event that something similar to the case described in the previous section occurs, and not be a privilege for domain name registrants.

Summary of Submission

I am in favour for the adoption of the .internal. string as reserved TLD for local DNS resolution, and I think that every manufacturer, network administrator or owner of network device in their right mind should as well find themselves in agreement.

Not really a problem if it's a few more characters long, the DNS search domain feature may come in handy albeit it's not always the case. The word "internal" is really suggestive and makes it explicit that the host you're connected to is inside the local network, and you're unlikely to be wrong. I use subdomains like lan.internal or mgmt.internal and so on, hence I also don't care if the reserved string is just one (actually two if we consider, I think it's enough for every company, as well as for home use.

As for the 3rd criteria of choice, I think it might be **similar** to .int., but not **confusingly similar**, so that should not really be an issue.

To wrap this, I guess the whole global internet community should be thankful for this change that may seem a trifle to many people's eyes, whereas in reality it is both an achievement and a relief to what has been a long-standing pain for ages, especially when dealing with the arrangement of the local DNS namespace when managing multiple private subnets.