| Internet-Draft | Private use top-level domain | December 2025 |
| Davies, et al. | Expires 4 July 2026 | [Page] |
This document describes 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 4 July 2026.¶
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.¶
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 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 private networks as the network operator sees fit. It fulfills a purpose similar to private-use IP address ranges (e.g. [RFC1918]), but in the DNS.¶
Network operators have been using using a variety of unregistered 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. This name could later appear in the global DNS, thereby causing name collisions and undefined behavior for users.¶
In almost all cases, an entity should use a sub-domain 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. Entities choosing to do so should be cognizant of the implications of this decision, including:¶
The potential for collisions if multiple networks using "internal" are interconnected in the future¶
The risk of leakage of "internal" names into the global DNS, and¶
The lack of global uniqueness of "internal" names and¶
DNSSEC validating resolvers relying on the global DNS trust anchor will fail to resolve names ending in "internal".¶
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 with the Home Networking Control Protocol [RFC7788].¶
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.¶
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.¶
Given the lack of uniqueness, users should be aware that collisions may occur if the same name is used in different "internal" networks, for example if two organizations using "internal" interconnect their networks. This is similar to the potential for IP address collisions when interconnecting networks using private-use IP address ranges (e.g., [RFC1918]). Organizations should consider these implications when deciding whether to use 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 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" namespace 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.¶
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. DNS records within this top-level domain will not be 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]¶
I-D source is maintained at: https://github.com/kjd/draft-davies-internal-tld¶