



Network Working Group                                          K. Davies
Internet-Draft                                                      IANA
Intended status: Informational                             A. McConachie
Expires: 4 July 2026                                               ICANN
                                                               W. Kumari
                                                                  Google
                                                        31 December 2025


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

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 July 2026.

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 July 2026                  [Page 1]

Internet-Draft        Private use top-level domain         December 2025


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.  Informative References  . . . . . . . . . . . . . . . . . . .   4
   Notes (for removal before publication)  . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

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

2.  Using the "internal" Namespace

   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:

   1.  The potential for collisions if multiple networks using
       "internal" are interconnected in the future

   2.  The risk of leakage of "internal" names into the global DNS, and



Davies, et al.             Expires 4 July 2026                  [Page 2]

Internet-Draft        Private use top-level domain         December 2025


   3.  The lack of global uniqueness of "internal" names and

   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 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



Davies, et al.             Expires 4 July 2026                  [Page 3]

Internet-Draft        Private use top-level domain         December 2025


   "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.

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.

   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.  Informative References






Davies, et al.             Expires 4 July 2026                  [Page 4]

Internet-Draft        Private use top-level domain         December 2025


   [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>.

   [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





Davies, et al.             Expires 4 July 2026                  [Page 5]

Internet-Draft        Private use top-level domain         December 2025


   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 4 July 2026                  [Page 6]
