summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9120.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc9120.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc9120.txt')
-rw-r--r--doc/rfc/rfc9120.txt284
1 files changed, 284 insertions, 0 deletions
diff --git a/doc/rfc/rfc9120.txt b/doc/rfc/rfc9120.txt
new file mode 100644
index 0000000..5e540e6
--- /dev/null
+++ b/doc/rfc/rfc9120.txt
@@ -0,0 +1,284 @@
+
+
+
+
+Internet Architecture Board (IAB) K. Davies
+Request for Comments: 9120 J. Arkko
+Updates: 3172 October 2021
+Category: Informational
+ISSN: 2070-1721
+
+
+ Nameservers for the Address and Routing Parameter Area ("arpa") Domain
+
+Abstract
+
+ This document describes revisions to operational practices to
+ separate the function of the "arpa" top-level domain in the DNS from
+ its historical operation alongside the DNS root zone.
+
+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 Architecture Board (IAB)
+ and represents information that the IAB has deemed valuable to
+ provide for permanent record. It represents the consensus of the
+ Internet Architecture Board (IAB). Documents approved for
+ publication by the IAB are not 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/rfc9120.
+
+Copyright Notice
+
+ Copyright (c) 2021 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.
+
+Table of Contents
+
+ 1. Introduction
+ 2. Requirements for the "arpa" Zone
+ 3. Transition Process
+ 3.1. Dedicated Nameserver Hostnames
+ 3.2. Separation of Infrastructure
+ 3.3. Zone Administration
+ 3.4. Conclusion of Process
+ 4. IANA Considerations
+ 5. Security Considerations
+ 6. References
+ 6.1. Normative References
+ 6.2. Informative References
+ IAB Members at the Time of Approval
+ Acknowledgments
+ Authors' Addresses
+
+1. Introduction
+
+ The "arpa" top-level domain [RFC3172] is designated as an
+ "infrastructure domain" to support techniques defined by Internet
+ standards. Zones under the "arpa" domain provide various mappings,
+ such as IP addresses to domain names and E.164 numbers to URIs. It
+ also contains special-use names such as "home", which is a nonunique
+ name used in residential networks.
+
+ Historically, the "arpa" zone has been hosted on almost all of the
+ root nameservers (NSs), and [RFC3172] envisages the "arpa" domain to
+ be "sufficiently critical that the operational requirements for the
+ root servers apply to the operational requirements of the "arpa"
+ servers". To date, this has been implemented by serving the "arpa"
+ domain directly on a subset of the root server infrastructure.
+
+ This bundling of root nameserver and "arpa" nameserver operations has
+ entwined management of the zones' contents and their infrastructures.
+ As a result, some proposals under consideration by the IETF involving
+ the "arpa" zone have been discarded due to the risk of conflict with
+ operations associated with managing the content of the root zone or
+ administering the root nameservers.
+
+ The separation described in this document resolves the operational
+ impacts of synchronizing edits to the root zone and the "arpa" zone
+ by eliminating the current dependency and allowing more tailored
+ operations based on the unique requirements of each zone.
+
+2. Requirements for the "arpa" Zone
+
+ The "arpa" domain continues to play a role in critical Internet
+ operations, and this change does not propose weakening operational
+ requirements described in [RFC3172] for the domain. Future
+ operational requirements for the "arpa" domain are encouraged to
+ follow strong baseline requirements such as those documented in
+ [RFC7720].
+
+ Changes to the administration of the "arpa" zone do not alter the
+ management practices of other zones delegated within the "arpa"
+ namespace. For example, "ip6.arpa" would continue to be managed in
+ accordance with [RFC5855].
+
+3. Transition Process
+
+ The process will dedicate new hostnames to the servers that are
+ authoritative for the "arpa" zone, but it will initially serve the
+ "arpa" zone from the same hosts.
+
+ Once completed, subsequent transitional phases could include using
+ new hosts to replace or augment the existing root nameserver hosts
+ and separating the editing and distribution of the "arpa" zone from
+ necessarily being connected to the root zone. Any future management
+ considerations regarding how such changes may be performed are beyond
+ the scope of this document.
+
+3.1. Dedicated Nameserver Hostnames
+
+ Consistent with the use of the "arpa" namespace itself to host
+ nameservers for other delegations in the "arpa" zone [RFC5855], this
+ document specifies a new namespace of "ns.arpa", with the nameserver
+ set for the "arpa" zone to be initially labeled as follows:
+
+ a.ns.arpa
+ b.ns.arpa
+ c.ns.arpa
+ ...
+
+ Dedicated hostnames eliminate a logical dependency that requires the
+ coordinated editing of the nameservers for the "arpa" zone and the
+ root zone. This component of this transition does not require that
+ the underlying hosts that provide "arpa" name service (that is, the
+ root nameservers) be altered. The "arpa" zone will initially map the
+ new hostnames to the same IP addresses that already provide service
+ under the respective hostnames within "root-servers.net".
+
+ Because these nameservers are completely within the "arpa" zone, they
+ will require glue records in the root zone. This is consistent with
+ current practice and requires no operational changes to the root
+ zone.
+
+3.2. Separation of Infrastructure
+
+ After initially migrating the "arpa" zone to use hostnames that are
+ not shared with the root zone, the underlying name service is
+ expected to evolve such that it no longer directly aligns with a
+ subset of root nameserver instances. With no shared infrastructure
+ between the root nameservers and the "arpa" nameservers, future novel
+ applications for the "arpa" zone may be possible.
+
+ Any subsequent change to the parties providing name service for the
+ zone is considered a normal management responsibility and would be
+ performed in accordance with [RFC3172].
+
+3.3. Zone Administration
+
+ Publication of the "arpa" zone file to the authoritative "arpa"
+ nameservers is currently undertaken alongside the root zone
+ maintenance functions. Upon the separation of the "arpa"
+ infrastructure from the root nameserver infrastructure, publication
+ of the "arpa" zone no longer necessarily needs to be technically
+ linked or interrelated to the root zone publication mechanisms.
+
+3.4. Conclusion of Process
+
+ Full technical separation of operations of the "arpa" zone and root
+ zone minimally requires the following to be satisfied:
+
+ * The "arpa" zone no longer shares any hostnames in its nameserver
+ set with the root zone.
+
+ * The hosts that provide authoritative name service are not the same
+ hosts as the root nameservers, do not share any IPv4 or IPv6
+ addresses with the root servers, and are sufficiently provisioned
+ separately such that any unique "arpa" zone requirements can be
+ deployed without affecting how root zone service is provided.
+
+ * The editorial and publication process for the "arpa" zone removes
+ any common dependencies with the root zone process so that the
+ "arpa" zone can be managed, edited, and provisioned wholly
+ independently of the root zone.
+
+ Such separation is ultimately sought to allow for novel uses of the
+ "arpa" zone without the risk of inadvertently impacting root zone and
+ root server operations. It is recognized that achieving this state
+ requires a deliberative process involving significant coordination to
+ ensure impacts are minimized.
+
+4. IANA Considerations
+
+ IANA shall coordinate the creation of the "ns.arpa" namespace and
+ populate it with address records that reflect the IP addresses of the
+ contemporary root servers documented within "root-servers.net" as its
+ initial state. The namespace may be provisioned either directly
+ within the "arpa" zone (as an empty nonterminal) or through
+ establishing a dedicated "ns.arpa" zone, according to operational
+ requirements.
+
+ IANA will initially migrate the 12 NS records for the "arpa" zone to
+ point to their respective new entries in the "ns.arpa" domain.
+
+ When these actions are complete, the IAB and IANA will consult and
+ coordinate with all relevant parties on activity to reduce or
+ eliminate reliance upon the root zone and root server infrastructure
+ serving the "arpa" zone. Such changes will be performed in
+ compliance with [RFC3172] and shall be conducted with all due care
+ and deliberation to mitigate potential impacts on critical
+ infrastructure.
+
+5. Security Considerations
+
+ The security of the "arpa" zone is not necessarily impacted by any
+ aspects of these changes. Robust practices associated with
+ administering the content of the zone (including signing the zone
+ with DNSSEC) as well as its distribution will continue to be
+ necessary.
+
+6. References
+
+6.1. Normative References
+
+ [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>.
+
+6.2. Informative References
+
+ [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6
+ Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855,
+ May 2010, <https://www.rfc-editor.org/info/rfc5855>.
+
+ [RFC7720] Blanchet, M. and L-J. Liman, "DNS Root Name Service
+ Protocol and Deployment Requirements", BCP 40, RFC 7720,
+ DOI 10.17487/RFC7720, December 2015,
+ <https://www.rfc-editor.org/info/rfc7720>.
+
+IAB Members at the Time of Approval
+
+ Internet Architecture Board members at the time this document was
+ approved for publication were:
+
+ Jari Arkko
+ Deborah Brungard
+ Ben Campbell
+ Lars Eggert
+ Wes Hardaker
+ Cullen Jennings
+ Mirja Kühlewind
+ Zhenbin Li
+ Jared Mauch
+ Tommy Pauly
+ David Schinazi
+ Russ White
+ Jiankang Yao
+
+Acknowledgments
+
+ Thank you Alissa Cooper, Michelle Cotton, Lars-Johan Liman, Wes
+ Hardaker, Ted Hardie, Paul Hoffman, Russ Housley, Oscar Robles-Garay,
+ Duane Wessels, and Suzanne Woolf for providing review and feedback.
+
+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
+
+
+ Jari Arkko
+ Ericsson Research
+ 02700 Kauniainen
+ Finland
+
+ Email: jari.arkko@ericsson.com