RFC 9121 INFORMATIONAL INFRASTRUCTURE · DNS

Deprecating int domains: Deprecating Infrastructure "int" Domains

Retiring old internet infrastructure names from the int domain.

On rfc-editor.org ↗
PUBLISHED
April 2023
AUTHORS
K. Davies, A. Baber
STREAM
IETF
BUILDS ON
RFC 1528 — Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures, RFC 1706 — DNS NSAP records
DEPRECATED DOMAINS
7 (atma.int, ip4.int, ip6.int, nsap.int, rdi.int, reg.int, tpc.int)
INFRASTRUCTURE INT ENDED
2001 (RFC 3172)
RFCS MOVED TO HISTORIC
RFC 1528, RFC 1706
DOI
10.17487/RFC9121

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Internet Engineering Task Force (IETF)                         K. Davies
Request for Comments: 9121                                      A. Baber
Obsoletes: 1528                                                     IANA
Updates: 1706                                                 April 2023
Category: Informational
ISSN: 2070-1721


                Deprecating Infrastructure "int" Domains

Abstract

   This document deprecates the use of any "int" domain names that were
   designated for infrastructure purposes by the IETF, and it identifies
   them for removal from the "int" top-level domain.  Any
   implementations that involve these domains are now deprecated.  This
   document also changes the status of RFC 1528 and RFC 1706 to
   Historic.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9121.

Copyright Notice

   Copyright (c) 2023 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.  Code Components extracted from this document must
   include Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Revised BSD License.

Table of Contents

   1.  Introduction
   2.  Historical Infrastructural Uses
     2.1.  atma.int
     2.2.  ip4.int
     2.3.  ip6.int
     2.4.  nsap.int
     2.5.  rdi.int
     2.6.  reg.int
     2.7.  tpc.int
   3.  Updates to Other RFC Series Documents
     3.1.  RFC 1528
     3.2.  RFC 1706
   4.  IANA Considerations
   5.  Security Considerations
   6.  Additional Information
   7.  Informative References
   Acknowledgments
   Authors' Addresses

1.  Introduction

   The "int" top-level domain [RFC1591] is a specialized domain
   designated for intergovernmental organizations, which are
   organizations established by international treaties between or among
   national governments.

   Historically, the "int" domain was also used for purposes related to
   Internet infrastructure.  This practice ended in 2001 when the "arpa"
   domain was declared the appropriate home for infrastructural
   identifier spaces [RFC3172].  In conjunction with this change, the
   eligibility for "int" domains was limited to only intergovernmental
   treaty organizations.

   The documented uses of infrastructural identifiers in the "int"
   domain were largely experimental and are now, in practice, obsolete.
   This document changes the status of related specifications to
   Historic, and it removes any associated delegations from the "int"
   zone in the domain name system.

2.  Historical Infrastructural Uses

   The following domains were used for infrastructural identifier
   purposes that are now considered historic.  Although each of these
   names was either delegated or documented at one time, the parties
   administering them have long since stopped using them.

2.1.  atma.int

   The atma.int domain was experimentally defined to implement address
   lookups for Asynchronous Transfer Mode (ATM), including ATM End
   System Addresses (AESAs) [ANS].

2.2.  ip4.int

   The ip4.int domain was described as providing an alternative to the
   in-addr.arpa domain for mapping host IPv4 addresses to host names.
   The in-addr.arpa domain zone continues to be administered for this
   purpose [RFC1035].

2.3.  ip6.int

   The ip6.int domain was originally delegated for mapping host IPv6
   addresses to host names.  It was subsequently removed from the "int"
   zone, having been replaced by ip6.arpa [RFC4159].

2.4.  nsap.int

   The nsap.int domain name was specified to experimentally map Open
   Systems Interconnection (OSI) Network Service Access Points to domain
   names [RFC1706].

2.5.  rdi.int

   The rdi.int domain name experimentally mapped OSI Inter-Domain
   Routing Protocol's Routing Domain Identifiers [ISO10747] to the
   domain name system.

2.6.  reg.int

   The reg.int domain name hosted an experimental mechanism for
   publishing IANA registration values in the domain name system.

2.7.  tpc.int

   The tpc.int domain name hosted an experimental remote printing
   service that served as a gateway between Internet mail and facsimile
   transmission [RFC1528].

3.  Updates to Other RFC Series Documents

3.1.  RFC 1528

   The specification for tpc.int [RFC1528] is Historic, as it no longer
   functions as described in the document.

3.2.  RFC 1706

   The specification for nsap.int [RFC1706] is Historic, as it no longer
   functions as described in the document.

4.  IANA Considerations

   IANA has removed the historical "int" domains discussed in this
   document.

5.  Security Considerations

   Some old systems might have one or more subdomains of these names
   hardwired and expect a positive response for at least the second-
   level domain.  This is, of course, true for any name in the DNS and
   should not be the sole basis for retaining obsolete names.

   Existing applications should eliminate any reliance upon these zones.
   The operator of the "int" domain should be cautious about any
   potential re-use of these domains for intergovernmental treaty
   organizations.

6.  Additional Information

   This document is the result of a comprehensive inventory of .int
   domains to accurately establish and record their purpose based on
   historical documentation.  As part of this inventory, IANA studied
   the domains delegated for purposes related to infrastructure
   identifiers.  Query patterns in the DNS for these domains were
   analyzed and judged to be insignificant; preliminary outreach to the
   contacts for the associated domains was conducted.  The assessment
   concluded that these domains are very likely obsolete.  This document
   formalizes that assessment.

   There are a small number of nominal "int" domains for "international
   databases" that are not defined by any standards documentation.  They
   are assigned to entities rather than for identifier purposes.  Their
   dispositions are beyond the scope of this memo.

7.  Informative References

   [ANS]      The ATM Forum Technical Committee, "ATM Name System
              Specification Version 1.0", ATM Forum af-saa-0069.000,
              November 1996, <https://www.broadband-
              forum.org/technical/download/af-saa-0069.000.pdf>.

   [ISO10747] ISO/IEC, "Information technology - Telecommunications and
              information exchange between systems - Protocol for
              exchange of inter-domain routeing information among
              intermediate systems to support forwarding of ISO 8473
              PDUs", ISO/IEC 10747:1994, October 1994,
              <https://www.iso.org/standard/21417.html>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC1528]  Malamud, C. and M. Rose, "Principles of Operation for the
              TPC.INT Subdomain: Remote Printing -- Technical
              Procedures", RFC 1528, DOI 10.17487/RFC1528, October 1993,
              <https://www.rfc-editor.org/info/rfc1528>.

   [RFC1591]  Postel, J., "Domain Name System Structure and Delegation",
              RFC 1591, DOI 10.17487/RFC1591, March 1994,
              <https://www.rfc-editor.org/info/rfc1591>.

   [RFC1706]  Manning, B. and R. Colella, "DNS NSAP Resource Records",
              RFC 1706, DOI 10.17487/RFC1706, October 1994,
              <https://www.rfc-editor.org/info/rfc1706>.

   [RFC3172]  Huston, G., Ed., "Management Guidelines & Operational
              Requirements for the Address and Routing Parameter Area
              Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
              September 2001, <https://www.rfc-editor.org/info/rfc3172>.

   [RFC4159]  Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
              DOI 10.17487/RFC4159, August 2005,
              <https://www.rfc-editor.org/info/rfc4159>.

Acknowledgments

   This document was compiled with help from Ted Hardie and Michelle
   Cotton, with additional input from Jari Arkko, John Klensin, Warren
   Kumari, Pete Resnick, George Michaelson, and Toerless Eckert.

Authors' Addresses

   Kim Davies
   Internet Assigned Numbers Authority
   PTI/ICANN
   12025 Waterfront Drive
   Los Angeles, CA 90094
   United States of America
   Email: kim.davies@iana.org


   Amanda Baber
   Internet Assigned Numbers Authority
   PTI/ICANN
   12025 Waterfront Drive
   Los Angeles, CA 90094
   United States of America
   Email: amanda.baber@iana.org

AI ELI5

On this page
PROBLEMThe int top-level domain was historically used for internet infrastructure purposes, but these experimental uses are now obsolete and should be cleaned up.
MECHANISMThis document identifies seven historical int subdomains (atma.int, ip4.int, ip6.int, nsap.int, rdi.int, reg.int, tpc.int) and marks them as deprecated, with their specifications moved to Historic status.
STATUS TODAYThe int domain is now reserved solely for intergovernmental treaty organizations, and related RFCs 1528 and 1706 are reclassified as Historic.

§1Why the int Domain Was Cleaned Up

The int top-level domain is a specialized naming space reserved for intergovernmental organizations established by international treaties. However, in the early days of the internet, this domain was also used experimentally for infrastructure purposes—ways the internet plumbing identified itself in the domain name system.

In 2001, RFC 3172 established that the arpa domain was the proper home for such infrastructure identifiers. This policy change meant no new int domains could be created for infrastructure, but the old experimental ones remained. Over time, the organizations using them stopped, and these domains became obsolete. This document formally deprecates them.

The int domain was an old experimental playground for internet infrastructure names, but it was declared off-limits for that purpose in 2001. Now we are officially closing down the unused old experiments.

§2The Seven Deprecated Domains

The RFC lists seven infrastructure int subdomains that are now deprecated:

  • atma.int — experimental address lookups for Asynchronous Transfer Mode (ATM) end systems
  • ip4.int — an alternative to in-addr.arpa for mapping IPv4 addresses to names (in-addr.arpa is still in use)
  • ip6.int — originally delegated for IPv6 address mapping, but replaced by ip6.arpa and removed from the int zone
  • nsap.int — experimental mapping of Open Systems Interconnection (OSI) Network Service Access Points to domain names
  • rdi.int — experimental mapping of OSI routing domain identifiers
  • reg.int — hosted an experimental mechanism for publishing IANA registration values in DNS
  • tpc.int — hosted an experimental remote printing service bridging email and facsimile transmission

Although each was either delegated or documented at some point, the parties administering them stopped using them long ago.

There were seven old experimental address systems hidden under the int domain—for ATM, IPv4, IPv6, OSI protocols, and a fax service. None of them work anymore because the organizations that set them up abandoned them decades ago.

§3Security and Cleanup Implications

Some old systems might have these domain names hardwired in their configuration and expect a positive DNS response. However, this is true for any obsolete name in DNS and should not be sufficient reason to keep them. Existing applications should eliminate any reliance on these zones.

The operator of the int domain should be cautious about any potential re-use of these domain names for legitimate intergovernmental treaty organizations, as the old registrations may create confusion or conflicts. The RFC notes that IANA has formally removed all delegations for these historical int domains from the DNS.

Some very old programs might look for these domains and get confused when they disappear, but that's okay because those programs should have been updated long ago. The cleanup also means nobody can accidentally reuse these names and cause confusion.

§4Formal Status Changes

This document changes the status of two related RFCs to Historic:

  • RFC 1528 (the specification for tpc.int and its remote printing service) is now Historic.
  • RFC 1706 (the specification for nsap.int and DNS NSAP resource records) is now Historic.

The int domain is now reserved exclusively for intergovernmental treaty organizations, and the arpa domain remains the proper home for internet infrastructure identifier spaces.

Two old instruction manuals for these systems are officially put on the shelf as "history"—they still exist for reference if someone wants to understand what we tried, but they do not describe anything that currently works.

§5References