RFC 9121: Deprecating Infrastructure "int" Domains

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

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

3. Updates to Other RFC Series Documents

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

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