]> 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 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. ).

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 when, and only when, they appear in all capitals, as shown here. This document assumes familiarity with DNS terms; please see .

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. 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 always fail to resolve names ending in "internal". An organization wanting to use such names inside of their organization MAY want to sign and validate names ending in "internal" within their organization. The details of such configuration are outside the scope of this document.

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 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 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 the Home Networking Control Protocol .

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.

Domain Name Reservation Considerations (Editor note (WK): It not yet decided if .internal should be added to the list of special-use domain names at https://www.iana.org/assignments/special-use-domain-names/. Below are potential answers for the "Seven Questions" from , to help drive this discussion. These answers were lifted from other documents which made similar reservations, because “Good artists copy; great artists steal.” -- Pablo Picasso) Answer 1: copied from . Additional sentence added to make it more explicit. Answer 2: copied from , Sec 6.5. "Domain Name Reservation Considerations for Example Domains". Additional text about potential special handling for cookies. Answers 3 and 4: copied from , Sec 6.5. "Domain Name Reservation Considerations for Example Domains". Answers 5 and 6: copied from , Sec 6.1 "Domain Name Reservation Considerations for Private Addresses". Answer 7: copied from . Users SHOULD understand that .internal names are not expected to be globally unique, and may resolve to different addresses and services on different networks. Since there is no central authority responsible for assigning .internal names, users SHOULD be aware of this and SHOULD exercise appropriate caution.  In an untrusted or unfamiliar network environment, users SHOULD be aware that using a name like "www.internal" may not actually connect them to the web site they expected, and could easily connect them to a different web page, or even a fake or spoof of their intended web site, designed to trick them into revealing confidential information.  As always with networking, end-to-end cryptographic security can be a useful tool. For example, when connecting with ssh, the ssh host key verification process will inform the user if it detects that the identity of the entity they are communicating with has changed since the last time they connected to that name. Application software, in general, SHOULD NOT recognize .internal names as special and SHOULD use .internal names as they would other domain names. An exception to this may be web browsers (and similar) which may wish to institute special handling for cookies, such as invalidation when a network change is detected. Name resolution APIs and libraries SHOULD NOT recognize .internal names as special and SHOULD NOT treat them differently.  Name resolution APIs SHOULD send queries for .internal names to their configured caching DNS server(s). Caching DNS servers SHOULD NOT recognize .internal names as special and SHOULD resolve them normally. Authoritative DNS servers SHOULD recognize these names as special and SHOULD, by default, generate immediate negative responses for all such queries, unless explicitly configured by the administrator to give positive answers for names within the .internal zone. DNS server operators SHOULD, if they are using .internal names, configure their authoritative DNS servers to act as authoritative for these names. DNS Registries/Registrars MUST NOT grant requests to register any of these names in the normal way to any person or entity. 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 as if it were a normal DNS domain name will probably not work as desired, for reasons 4, 5 and 6 above.

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 private-use name 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.

Additional Information This reservation is the result of a community deliberation on this topic over many years, most notably . 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 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.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. 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. This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names. 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) It is currently assumed this domain should NOT be designated as a special-use domain name at https://www.iana.org/assignments/special-use-domain-names/. I-D source is maintained at: https://github.com/kjd/draft-davies-internal-tld