A Top-level Domain for Private Use
draft-davies-internal-tld-06
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Kim Davies , Andrew McConachie , Warren Kumari | ||
| Last updated | 2026-05-06 | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | ISE state | Response to Review Needed | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-davies-internal-tld-06
Network Working Group K. Davies
Internet-Draft IANA
Intended status: Informational A. McConachie
Expires: 7 November 2026 ICANN
W. Kumari
Google
6 May 2026
A Top-level Domain for Private Use
draft-davies-internal-tld-06
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 7 November 2026.
Copyright Notice
Copyright (c) 2026 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 7 November 2026 [Page 1]
Internet-Draft Private use top-level domain May 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Using the "internal" Namespace . . . . . . . . . . . . . . . 2
3. Comparisons to Similar Namespaces . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 3
6. Additional Information . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
8. Informative References . . . . . . . . . . . . . . . . . . . 5
Notes (for removal before publication) . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. 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 by 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. Domains under this TLD are not resolvable in the
global DNS but can be configured and utilized within private networks
according to the operator's requirements. This concept is analogous
to private-use IP address ranges (e.g., [RFC1918]), providing a
similar function within the DNS ecosystem.
2. 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 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:
1. The potential for collisions if multiple networks using
"internal" are interconnected in the future.
Davies, et al. Expires 7 November 2026 [Page 2]
Internet-Draft Private use top-level domain May 2026
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".
3. 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 with the Home Networking Control
Protocol [RFC7788].
4. IANA Considerations
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.
5. 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.
Davies, et al. Expires 7 November 2026 [Page 3]
Internet-Draft Private use top-level domain May 2026
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.,
[RFC1918]) 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 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.
6. 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. DNS records within this top-level domain
will not be resolvable in contexts outside of a private network.
Davies, et al. Expires 7 November 2026 [Page 4]
Internet-Draft Private use top-level domain May 2026
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]
7. 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 Hardakerm
Paul Hoffman, Philip Homburg, David Lawrence, John Levine, Benno
Overeinder, Petr Špaček, Ondrej Surý, Peter Thomassen and Suzanne
Woolf.
8. Informative References
[IANA-Assessment]
"Identification of a top-level domain for private use",
January 2024, <https://itp.cdn.icann.org/en/files/root-
system/identification-tld-private-use-24-01-2024-en.pdf>.
[ICANN-Board-Resolution]
"Reserving .INTERNAL for Private-Use Applications", July
2024, <https://www.icann.org/en/board-activities-and-
meetings/materials/approved-resolutions-special-meeting-
of-the-icann-board-29-07-2024-en#section2.a>.
[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, <https://www.rfc-editor.org/rfc/rfc1918>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/rfc/rfc6762>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <https://www.rfc-editor.org/rfc/rfc7788>.
[RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain
'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018,
<https://www.rfc-editor.org/rfc/rfc8375>.
Davies, et al. Expires 7 November 2026 [Page 5]
Internet-Draft Private use top-level domain May 2026
[RFC9476] Kumari, W. and P. Hoffman, "The .alt Special-Use Top-Level
Domain", RFC 9476, DOI 10.17487/RFC9476, September 2023,
<https://www.rfc-editor.org/rfc/rfc9476>.
[SAC113] "SSAC Advisory on Private-Use TLDs", September 2020,
<https://itp.cdn.icann.org/en/files/security-and-
stability-advisory-committee-ssac-reports/sac-113-en.pdf>.
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
Email: warren@kumari.net
Davies, et al. Expires 7 November 2026 [Page 6]