diff options
Diffstat (limited to 'doc/rfc/rfc9120.txt')
| -rw-r--r-- | doc/rfc/rfc9120.txt | 284 |
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 |