Network Working Group K. Davies Internet-Draft IANA Intended status: Informational A. McConachie Expires: 4 September 2025 ICANN W. Kumari Google 3 March 2025 A Top-level Domain for Private Use draft-davies-internal-tld-03 Abstract This document describes the "internal" top-level domain for use in private applications. Status of This Memo 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 4 September 2025. Copyright Notice Copyright (c) 2025 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. Davies, et al. Expires 4 September 2025 [Page 1] Internet-Draft Private use top-level domain March 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Using the "internal" Namespace . . . . . . . . . . . . . . . 2 4. Comparisons to Similar Namespaces . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 5.1. Domain Name Reservation Considerations . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Additional Information . . . . . . . . . . . . . . . . . . . 6 8. Informative References . . . . . . . . . . . . . . . . . . . 6 Notes (for removal before publication) . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction There are certain circumstances in which 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 provides 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. It fulfils a similar purpose as private-use IP address ranges that are set aside (e.g. [RFC1918]). 2. Terminology 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]. 3. Using the "internal" Namespace Network operators have been using different names for private-use DNS for many years. This usage has been uncoordinated and can 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. Davies, et al. Expires 4 September 2025 [Page 2] Internet-Draft Private use top-level domain March 2025 If an organization determines that it requires a private-use DNS namespace, it should either use sub-domains of a global DNS name that is under its 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 or organizational needs, and is outside the scope of this publication. DNSSEC validating resolvers will fail to resolve names ending in "internal". 4. Comparisons to Similar Namespaces Other namespaces are reserved for similar purposes, which superficially may seem to serve the same purpose as the "internal" domain, but are intended for different use cases. * The "local" namespace [RFC6762] 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. It is expected "internal" will be used for applications where names are specified in locally-configured zones. * The "alt" namespace [RFC9476] 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 [RFC8375] is reserved for use within residential networks, including the Home Networking Control Protocol [RFC7788]. 5. IANA Considerations The document requires no IANA actions. For the reasons stated above, as the "internal" top-level domain is reserved from being used in the global DNS it MUST NOT appear in the DNS root zone except to the minimum extent necessary to enable it to function for its intended purpose. Davies, et al. Expires 4 September 2025 [Page 3] Internet-Draft Private use top-level domain March 2025 5.1. Domain Name Reservation Considerations (Editor note: It not yet decided if the "internal" top-level domain should be added to the list of special-use domain names at https://www.iana.org/assignments/special-use-domain-names/ (https://www.iana.org/assignments/special-use-domain-names/). These are potential answers for the "Seven Questions" from [RFC6761], to help drive this discussion, and are likely to change before publication. As suggested by Petr, these answers were lifted from [RFC6761], Section 6.1. - "Domain Name Reservation Considerations for Private Addresses" with minor edits to e.g replace "private addresses" with "internal names". The answer to question 5 was also rewritten.) 1. Users are free to use these names within the "internal" top-level domain as they would any other domain names. However, since there is no central authority responsible for use of these names, users should be aware that these names are likely to yield different results on different networks. 2. Application software SHOULD NOT recognize these names as special, and SHOULD use these names as they would other domain names 3. Name resolution APIs and libraries SHOULD NOT recognize these names as special and SHOULD NOT treat them differently. Name resolution APIs SHOULD send queries for these names to their configured caching DNS server(s). 4. Caching DNS servers SHOULD recognize these names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve these names. Instead, caching DNS servers SHOULD, by default, generate immediate (positive or negative) responses for all such queries. This is to avoid unnecessary load on the root name servers and other name servers. Caching DNS servers SHOULD offer a configuration option (disabled by default) to enable upstream resolution of such names, for use in private networks where names ending in ".internal" are known to be handled by an authoritative DNS server in that private network. 5. Authoritative DNS servers SHOULD NOT recognize these names as special unless explicitly configured by the administrator for names within the "internal" namespace. 6. DNS server operators SHOULD, if they are using names within the "internal" top-level domain, configure their authoritative DNS servers to act as authoritative for these names. Davies, et al. Expires 4 September 2025 [Page 4] Internet-Draft Private use top-level domain March 2025 7. DNS Registries/Registrars MUST NOT grant requests to register any of these names. These names are reserved for use in private networks, and fall outside the set of names available for allocation by registries/registrars. Attempting to allocate one of these names in the global DNS name will probably not work as desired, for reasons 4, 5 and 6 above. 6. Security Considerations 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. Since usage may appear in log files, email headers, and the like; users should not rely on the confidentiality of the "internal" namespace. Users should not expect that names in the "internal" namespace are globally unique; it is assumed that many of the same names will be used for entirely different purposes on different networks. This is similar to the use of the "local" namespace in the multicast DNS protocol - just as there are many different devices named "printer.local", there may be many different servers named "accounting.internal". Users should be aware of this when performing operations requiring authenticity, such as entering credentials. 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 name within the "internal" namespace can never be used by itself to identify the origin of a communication. The lack of global uniqueness also has implications for HTTP cookies; a cookie set for "accounting.internal" on one network may be sent to a different "accounting.internal" if the user changes their local network. This may be mitigated by adding the Secure flag to the cookie. It is expected that Certificate Authorities will not issue certificates for the "internal" namspace as it does not resolve in the global DNS. If an organization wants to use HTTP over TLS with names in the "internal" namespace, they will also need an internal, private CA. The details of this are outside the scope of this document. Davies, et al. Expires 4 September 2025 [Page 5] Internet-Draft Private use top-level domain March 2025 7. Additional Information 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. A selection process [IANA-Assessment] determined "internal" was the best suited string given the requirement that a single string be selected for this purpose, and subsequently reserved for this purpose in July 2024. [ICANN-Board-Resolution] 8. Informative References [BCP14] Best Current Practice 14, . At the time of writing, this BCP comprises the following: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [BCP219] Best Current Practice 219, . At the time of writing, this BCP comprises the following: Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . [IANA-Assessment] "Identification of a top-level domain for private use", January 2024, . [ICANN-Board-Resolution] "Reserving .INTERNAL for Private-Use Applications", July 2024, . Davies, et al. Expires 4 September 2025 [Page 6] Internet-Draft Private use top-level domain March 2025 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, . [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, . [RFC9476] Kumari, W. and P. Hoffman, "The .alt Special-Use Top-Level Domain", RFC 9476, DOI 10.17487/RFC9476, September 2023, . [SAC113] "SSAC Advisory on Private-Use TLDs", September 2020, . Notes (for removal before publication) * I-D source is maintained at: https://github.com/kjd/draft-davies- internal-tld (https://github.com/kjd/draft-davies-internal-tld) Authors' Addresses Kim Davies Internet Assigned Numbers Authority Email: kim.davies@iana.org Andrew McConachie Internet Corporation for Assigned Names and Numbers Email: andrew.mcconachie@icann.org Warren Kumari Google Davies, et al. Expires 4 September 2025 [Page 7] Internet-Draft Private use top-level domain March 2025 Email: warren@kumari.net Davies, et al. Expires 4 September 2025 [Page 8]