]> Internet Assigned Numbers Authority

kim.davies@iana.org

Internet Corporation for Assigned Names and Numbers

andrew.mcconachie@icann.org

Google

warren@kumari.net

Internet-Draft This document describes the "internal" top-level domain for use in private applications.

Introduction There are situations in which private network operators may wish to use their own domain naming scheme that is not intended to be used or accessible via the global domain name system (DNS), such as within corporate or home networks. The "internal" top-level domain (TLD) is specifically designated for this purpose. Names under this TLD are not resolvable in the global DNS but can be configured and used within private networks according to the operator's requirements. This concept is analogous to private-use IP address ranges (e.g., ), providing a similar function within the DNS ecosystem.

Using the "internal" Namespace Network operators have long relied on various unregistered names for private-use DNS, often in an uncoordinated manner. This practice can lead to incompatibilities and unintended consequences for Internet users. For instance, an organization might adopt a name for internal use that is later introduced into the global DNS, resulting in name collisions and unpredictable behavior. In almost all cases, an entity should use a subdomain of a global DNS name that it controls. This ensures that names are globally unique and avoids the potential for confusion that may arise from the use of private-use namespaces. However, in some cases, such as for isolated networks that will never be connected to the global Internet, use of the "internal" top-level domain may be appropriate. One such example could be for communication between services within containers and other virtualized environments. Entities choosing to do so should be cognizant of the implications of this decision, including:

1. The potential for collisions if multiple networks using "internal" are interconnected in the future.
2. The risk of leakage of "internal" names into the global DNS.
3. The lack of global uniqueness of "internal" names.
4. DNSSEC-validating resolvers relying on the global DNS trust anchor will fail to resolve names ending in "internal".

Comparisons to Similar Namespaces Several other reserved namespaces may superficially appear to serve the same purpose as "internal", but are intended for different use cases.

• The "local" namespace is reserved for use with the multicast DNS protocol. This protocol allows for resolution between devices on a local network. This namespace does not use typical DNS zones for name allocation, and instead uses the multicast DNS protocol to negotiate names and resolve conflicts. By contrast, "internal" is intended for applications where names are specified in locally configured zones.
• The "alt" namespace is reserved for contexts where identifiers are used that may look like domain names, but do not use the DNS protocol for resolution. This is in contrast to the "internal" domain which is to be used with the DNS protocol, but in limited private-use network scope.
• The "home.arpa" namespace is reserved for use within residential networks, including with the Home Networking Control Protocol .

IANA Considerations This document requires no IANA actions. The "internal" top-level domain has been reserved from delegation in the global DNS by the ICANN Board .

Security Considerations While the "internal" namespace is designated for private use, it is important to recognize its limitations and potential risks:

1. Leakage into the broader Internet: Names within the "internal" namespace may inadvertently appear in log files, email headers, or other contexts, leading to potential exposure. Users should not rely on the confidentiality of these names.
2. Lack of global uniqueness: Names in the "internal" namespace are not globally unique. For example, multiple networks may use the same name, such as "accounting.internal", for entirely different purposes. This is similar to the use of the "local" namespace in multicast DNS, where many devices might share the name "printer.local". Users should exercise caution when performing operations that require authenticity, such as entering credentials.
3. Collision risks: If two networks using the "internal" namespace are interconnected, name collisions may occur. This is analogous to IP address conflicts when private-use IP ranges (e.g., ) are interconnected. Organizations should carefully evaluate this risk before adopting the "internal" namespace.
4. DNSSEC limitations: DNSSEC-validating resolvers that rely on the global DNS trust anchor will fail to resolve names ending in "internal". This limitation should be considered when planning network configurations.
5. Implications for HTTP cookies: Cookies set for a domain like "accounting.internal" on one network may be sent to a different "accounting.internal" if the user switches networks. To mitigate this, organizations can use the Secure flag for cookies. Additionally, since the "internal" namespace does not resolve in the global DNS, Certificate Authorities are not expected to issue certificates for it. Organizations requiring HTTPS for "internal" domains will need to establish their own private Certificate Authority (CA), which is beyond the scope of this document.
6. Impacts on traceability: Users should not assume the appearance of such names is indicative of the true source of transmissions. When diagnosing network issues, the appearance of such names must be interpreted with the associated context to ascertain the private network with which the name is being used. A name within the "internal" namespace can never be used by itself to identify the origin of a communication.

Additional Information This reservation is the result of community deliberations on this topic over many years, culminating in . The SAC113 advisory recommended the establishment of a single top-level domain for private-use applications. A selection process determined that "internal" was the best-suited string given the requirement that a single string be selected, and the ICANN Board reserved it for this purpose in July 2024 .

Acknowledgments The authors would like to thank the members of the Internet community who participated in the discussions that led to the establishment of the "internal" top-level domain, including those who contributed to the SAC113 advisory and the IANA assessment process. The authors would especially like to thank Eliot Lear for extensive discussion and feedback on this document. Additional feedback and suggestions were received from Joe Abley, Mark Andrews, Wes Hardaker, Paul Hoffman, Philip Homburg, David Lawrence, John Levine, Benno Overeinder, Petr Špaček, Ondřej Surý, Peter Thomassen and Suzanne Woolf.

Informative References This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol, and a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol that supports routing based on both the source and destination address. This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.' and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. The Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'. This document reserves a Top-Level Domain (TLD) label "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers creating alternative namespaces.

Notes (for removal before publication)

• I-D source is maintained at: https://github.com/kjd/draft-davies-internal-tld