Skip to main content

A Top-level Domain for Private Use
draft-davies-internal-tld-06

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]