| Internet-Draft | Private use top-level domain | August 2024 |
| Davies & McConachie | Expires 3 February 2025 | [Page] |
This document describes the reservation of the ".internal" top-level domain for use in private applications.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 February 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
There are certain circumstances where private network operators may wish to use their own domain naming scheme that is not intended to be used or accessible by the global domain name system (DNS), such as within closed corporate or home networks.¶
The "internal" top-level domain is reserved to provide this purpose in the DNS. Such domains will not resolve in the global DNS, but can be configured within closed networks as the network operator sees fit.¶
This reservation is intended for a similar purpose that private-use IP address ranges that are set aside (e.g. [RFC1918]).¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP14] when, and only when, they appear in all capitals, as shown here.¶
This document assumes familiarity with DNS terms; please see [BCP219].¶
Network operators have been using different names for private-use DNS for many years. This usage is uncoordinated and could result in incompatibilities or harm to Internet users. For example, an organization might choose to use a name for this purpose that has not been assigned to them, that would later appear in the global DNS thereby causing name collisions and undefined behavior for users.¶
If an organization determines that they require a private-use DNS namespace, they should either use sub-domains of a global DNS name that is under their organizational and operational control, or use the "internal" top-level domain. This document does not offer guidance on when a network operators should choose the "internal" top-level domain instead of a sub-domain of a global DNS name. This decision will depend on multiple factors such as network design and organizational needs and is outside the scope of this publication.¶
The "internal" namespace and the "alt" namespace [RFC9476] have been reserved for different purposes. "alt" has been reserved for non-DNS contexts, whereas "internal" is intended for use with the DNS protocol for in a private-DNS context.¶
The document requires no IANA actions. For the reasons stated above, the "internal" top-level domain is reserved from being used in the global DNS and therefore MUST NOT appear in the DNS root zone.¶
While the namespace is designated for private use, there is no guarantee that the names utilized in this namespace will not leak into the broader Internet. Such usage may include appearance in log files, email headers, and the like. Users, therefore, should not rely on the confidentiality of the "internal" namespace.¶
Users should also not assume the appearance of such names is indicative of the true source of transmissions. When diagnosing network issues, the appearance of such addresses must be interpreted with the associated context to ascertain the private network with which the name is being used. A private-use name can never be used by itself to identify the origin of a communication. It is entirely likely that many of the same names will be used for entirely differnet purposes on different networks connected to the Internet.¶
This reservation is the result of a community deliberation on this topic over many years, most notably [SAC113]. The SAC113 advisory recommended the establishment of a single top-level domain for private-use applications. This top-level domain would not be delegated in the DNS root zone to ensure it is not resolvable in contexts outside of a private network.¶
ICANN implemented the recommendation of SAC113 through a process that first identified an appropriate selection procedure, and then conducted a selection process [IANA-Assessment] which determined "internal" was the best suited string given the requirement that a single string be selected for this purpose. The ICANN Board of Directors subsequently adopted this recommendation and formally decided the reservation in July 2024. [ICANN-Board-Resolution]¶
I-D source is maintained at: https://github.com/kjd/draft-davies-internal-tld¶
TBD¶