rfc9120.original   rfc9120.txt 
Network Working Group K. Davies Internet Architecture Board (IAB) K. Davies
Internet-Draft IANA Request for Comments: 9120 J. Arkko
Updates: 3172 (if approved) J. Arkko Updates: 3172 October 2021
Intended status: Informational Ericsson Category: Informational
Expires: January 13, 2022 July 12, 2021 ISSN: 2070-1721
Nameservers for the Address and Routing Parameter Area ("arpa") Domain Nameservers for the Address and Routing Parameter Area ("arpa") Domain
draft-iab-arpa-authoritative-servers-01
Abstract Abstract
This document describes revisions to operational practices to This document describes revisions to operational practices to
separate function of the "arpa" top-level domain in the DNS from its separate the function of the "arpa" top-level domain in the DNS from
historical operation alongside the DNS root zone. its historical operation alongside the DNS root zone.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Architecture Board (IAB)
and may be updated, replaced, or obsoleted by other documents at any and represents information that the IAB has deemed valuable to
time. It is inappropriate to use Internet-Drafts as reference provide for permanent record. It represents the consensus of the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on January 13, 2022. 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 Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document.
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Requirements for the "arpa" zone . . . . . . . . . . . . . . 3 2. Requirements for the "arpa" Zone
3. Transition Process . . . . . . . . . . . . . . . . . . . . . 3 3. Transition Process
3.1. Dedicated nameserver hostnames . . . . . . . . . . . . . 3 3.1. Dedicated Nameserver Hostnames
3.2. Separation of infrastructure . . . . . . . . . . . . . . 4 3.2. Separation of Infrastructure
3.3. Zone administration . . . . . . . . . . . . . . . . . . . 4 3.3. Zone Administration
3.4. Conclusion of process . . . . . . . . . . . . . . . . . . 4 3.4. Conclusion of Process
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. References
6.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.1. Normative References
6.2. Informative References . . . . . . . . . . . . . . . . . 5 6.2. Informative References
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 IAB Members at the Time of Approval
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Acknowledgments
Authors' Addresses
1. Introduction 1. Introduction
The "arpa" top-level domain [RFC3172] is designated as an The "arpa" top-level domain [RFC3172] is designated as an
"infrastructure domain" to support techniques defined by Internet "infrastructure domain" to support techniques defined by Internet
standards. Zones under the "arpa" domain provide various mappings, standards. Zones under the "arpa" domain provide various mappings,
such as IP addresses to domain names and E.164 numbers to URIs. It 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 non-unique also contains special-use names such as "home", which is a nonunique
name used in residential networks. name used in residential networks.
Historically, the "arpa" zone has been hosted on almost all of the Historically, the "arpa" zone has been hosted on almost all of the
root nameservers, and [RFC3172] envisages the "arpa" domain to be root nameservers (NSs), and [RFC3172] envisages the "arpa" domain to
"sufficiently critical that the operational requirements for the root be "sufficiently critical that the operational requirements for the
nameservers apply to the operational requirements of the "arpa" root servers apply to the operational requirements of the "arpa"
servers". To date, this has been implemented by serving the "arpa" servers". To date, this has been implemented by serving the "arpa"
domain directly on a subset of the root server infrastructure. domain directly on a subset of the root server infrastructure.
This bundling of root nameserver and "arpa" nameserver operations has This bundling of root nameserver and "arpa" nameserver operations has
entwined management of the zones' contents and their infrastructure. entwined management of the zones' contents and their infrastructures.
As a result, some proposals under consideration by the IETF involving As a result, some proposals under consideration by the IETF involving
the "arpa" zone have been discarded due to the risk of conflict with the "arpa" zone have been discarded due to the risk of conflict with
operations associated with managing the content of the root zone, or operations associated with managing the content of the root zone or
administering the root nameservers. administering the root nameservers.
The separation described in this document resolves operational The separation described in this document resolves the operational
impacts of synchronizing edits to the root zone and the "arpa" zone impacts of synchronizing edits to the root zone and the "arpa" zone
by eliminating the current dependency and allowing more tailored by eliminating the current dependency and allowing more tailored
operations based on the unique requirements of each zone. operations based on the unique requirements of each zone.
2. Requirements for the "arpa" zone 2. Requirements for the "arpa" Zone
The "arpa" domain continues to play a role in critical Internet The "arpa" domain continues to play a role in critical Internet
operations, and this change does not propose weakening operational operations, and this change does not propose weakening operational
requirements described in [RFC3172] for the domain. Future requirements described in [RFC3172] for the domain. Future
operational requirements for the "arpa" domain are encouraged to operational requirements for the "arpa" domain are encouraged to
follow strong baseline requirements such as those documented in follow strong baseline requirements such as those documented in
[RFC7720]. [RFC7720].
Changes to the administration of the "arpa" zone do not alter the Changes to the administration of the "arpa" zone do not alter the
management practices of other zones delegated within the "arpa" management practices of other zones delegated within the "arpa"
namespace. For example, "ip6.arpa" would continue to be managed in namespace. For example, "ip6.arpa" would continue to be managed in
accordance with [RFC5855]. accordance with [RFC5855].
3. Transition Process 3. Transition Process
The process will dedicate new hostnames to the servers authoritative The process will dedicate new hostnames to the servers that are
for the "arpa" zone, but will initially serve the "arpa" zone from authoritative for the "arpa" zone, but it will initially serve the
the same hosts. "arpa" zone from the same hosts.
Once completed, subsequent transitional phases could include using Once completed, subsequent transitional phases could include using
new hosts to replace or augment the existing root nameserver hosts, new hosts to replace or augment the existing root nameserver hosts
and separation of the editing and distribution of the "arpa" zone and separating the editing and distribution of the "arpa" zone from
from necessarily being connected to the root zone. Any future necessarily being connected to the root zone. Any future management
management considerations regarding how such changes may be performed considerations regarding how such changes may be performed are beyond
are beyond the scope of this document. the scope of this document.
3.1. Dedicated nameserver hostnames 3.1. Dedicated Nameserver Hostnames
Consistent with the use of the "arpa" namespace itself to host name Consistent with the use of the "arpa" namespace itself to host
servers for other delegations in the "arpa" zone ([RFC5855]), this nameservers for other delegations in the "arpa" zone [RFC5855], this
document specifies a new namespace of "ns.arpa", with the nameserver document specifies a new namespace of "ns.arpa", with the nameserver
set for the "arpa" zone to be initially labelled as follows: set for the "arpa" zone to be initially labeled as follows:
a.ns.arpa a.ns.arpa
b.ns.arpa b.ns.arpa
c.ns.arpa c.ns.arpa
... ...
Dedicated hostnames eliminate a logical dependency that requires the Dedicated hostnames eliminate a logical dependency that requires the
coordinated editing of the nameservers for the "arpa" zone and the coordinated editing of the nameservers for the "arpa" zone and the
root zone. This component of this transition does not require the root zone. This component of this transition does not require that
underlying hosts that provide "arpa" name service (that is, the root the underlying hosts that provide "arpa" name service (that is, the
nameservers) be altered. The "arpa" zone will initially map the new root nameservers) be altered. The "arpa" zone will initially map the
hostnames to the same IP addresses that already provide service under new hostnames to the same IP addresses that already provide service
the respective hostnames within root-servers.net. under the respective hostnames within "root-servers.net".
Because these nameservers are completely within the "arpa" zone, they Because these nameservers are completely within the "arpa" zone, they
will require glue records in the root zone. This is consistent with will require glue records in the root zone. This is consistent with
current practice and requires no operational changes to the root current practice and requires no operational changes to the root
zone. zone.
3.2. Separation of infrastructure 3.2. Separation of Infrastructure
After initially migrating the "arpa" zone to use hostnames that are After initially migrating the "arpa" zone to use hostnames that are
not shared with the root zone, the underlying name service is not shared with the root zone, the underlying name service is
expected to evolve such that it no longer directly aligns to a subset expected to evolve such that it no longer directly aligns with a
of root nameserver instances. With no shared infrastructure between subset of root nameserver instances. With no shared infrastructure
the root nameservers and the "arpa" nameservers, future novel between the root nameservers and the "arpa" nameservers, future novel
applications for the "arpa" zone may be possible. applications for the "arpa" zone may be possible.
Any subsequent changes to the parties providing name service for the Any subsequent change to the parties providing name service for the
zone is considered a normal management responsibility, and would be zone is considered a normal management responsibility and would be
performed in accordance with [RFC3172]. performed in accordance with [RFC3172].
3.3. Zone administration 3.3. Zone Administration
Publication of the "arpa" zone file to the authoritative "arpa" name Publication of the "arpa" zone file to the authoritative "arpa"
servers is currently undertaken alongside the root zone maintenance nameservers is currently undertaken alongside the root zone
functions. Upon the separation of the "arpa" infrastructure from the maintenance functions. Upon the separation of the "arpa"
root nameserver infrastructure, publication of the "arpa" zone no infrastructure from the root nameserver infrastructure, publication
longer necessarily needs to be technically linked or inter-related to of the "arpa" zone no longer necessarily needs to be technically
the root zone publication mechanisms. linked or interrelated to the root zone publication mechanisms.
3.4. Conclusion of process 3.4. Conclusion of Process
Full technical separation of operations of the "arpa" zone and root Full technical separation of operations of the "arpa" zone and root
zone minimally requires the following to be satisfied: zone minimally requires the following to be satisfied:
o The "arpa" zone no longer shares any hostnames in its NS-set with * The "arpa" zone no longer shares any hostnames in its nameserver
the root zone; set with the root zone.
o The hosts that provide authoritative name service are not the same * The hosts that provide authoritative name service are not the same
hosts as the root nameservers, do not share any IPv4 or IPv6 hosts as the root nameservers, do not share any IPv4 or IPv6
addresses with the root servers, and are sufficiently separately addresses with the root servers, and are sufficiently provisioned
provisioned such that any unique "arpa" zone requirements can be separately such that any unique "arpa" zone requirements can be
deployed without affecting how root zone service is provided; deployed without affecting how root zone service is provided.
o The editorial and publication process for the "arpa" zone has any * The editorial and publication process for the "arpa" zone removes
common dependencies with the root zone process removed, so that any common dependencies with the root zone process so that the
the "arpa" zone can be managed, edited and provisioned wholly "arpa" zone can be managed, edited, and provisioned wholly
independently of the root zone. independently of the root zone.
Such separation is ultimately sought to allow for novel uses of the Such separation is ultimately sought to allow for novel uses of the
"arpa" zone without the risk of inadvertantly impacting root zone and "arpa" zone without the risk of inadvertently impacting root zone and
root server operations. It is recognized that achieving this state root server operations. It is recognized that achieving this state
requires a deliberative process involving significant coordination to requires a deliberative process involving significant coordination to
ensure impacts are minimized. ensure impacts are minimized.
4. IANA Considerations 4. IANA Considerations
The IANA shall coordinate the creation of the "ns.arpa" namespace and IANA shall coordinate the creation of the "ns.arpa" namespace and
populate it with address records that reflect the IP addresses of the populate it with address records that reflect the IP addresses of the
contemporary root servers documented within "root-servers.net" as its contemporary root servers documented within "root-servers.net" as its
initial state. The namespace may either be provisioned directly initial state. The namespace may be provisioned either directly
within the "arpa" zone (as an empty non-terminal), or through within the "arpa" zone (as an empty nonterminal) or through
establishing a dedicated "ns.arpa" zone, according to operational establishing a dedicated "ns.arpa" zone, according to operational
requirements. requirements.
The IANA will initially migrate the 12 NS records for the "arpa" zone IANA will initially migrate the 12 NS records for the "arpa" zone to
to point to their respective new entries in the "ns.arpa" domain. point to their respective new entries in the "ns.arpa" domain.
Subsequently, the IAB and IANA will consult and coordinate with all When these actions are complete, the IAB and IANA will consult and
relevant parties on activity to reduce or eliminate reliance upon coordinate with all relevant parties on activity to reduce or
root zone and root server infrastructure for serving the "arpa" zone. eliminate reliance upon the root zone and root server infrastructure
Such changes will be performed in compliance with [RFC3172] and shall serving the "arpa" zone. Such changes will be performed in
be conducted with all due care and deliberation to mitigate potential compliance with [RFC3172] and shall be conducted with all due care
impacts on critical infrastructure. and deliberation to mitigate potential impacts on critical
infrastructure.
5. Security Considerations 5. Security Considerations
The security of the "arpa" zone is not necessarily impacted by any The security of the "arpa" zone is not necessarily impacted by any
aspects of these changes. Robust practices associated with aspects of these changes. Robust practices associated with
administering the content of the zone (including signing the zone administering the content of the zone (including signing the zone
with DNSSEC) as well as its distribution will continue to be with DNSSEC) as well as its distribution will continue to be
necessary. necessary.
6. References 6. References
skipping to change at page 6, line 10 skipping to change at line 238
[RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6
Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855, Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855,
May 2010, <https://www.rfc-editor.org/info/rfc5855>. May 2010, <https://www.rfc-editor.org/info/rfc5855>.
[RFC7720] Blanchet, M. and L-J. Liman, "DNS Root Name Service [RFC7720] Blanchet, M. and L-J. Liman, "DNS Root Name Service
Protocol and Deployment Requirements", BCP 40, RFC 7720, Protocol and Deployment Requirements", BCP 40, RFC 7720,
DOI 10.17487/RFC7720, December 2015, DOI 10.17487/RFC7720, December 2015,
<https://www.rfc-editor.org/info/rfc7720>. <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 Acknowledgments
Thank you Alyssa Cooper, Michelle Cotton, Lars-Johan Liman, Wes Thank you Alissa Cooper, Michelle Cotton, Lars-Johan Liman, Wes
Hardaker, Ted Hardie, Paul Hoffman, Russ Housley, Oscar Robles-Garay, Hardaker, Ted Hardie, Paul Hoffman, Russ Housley, Oscar Robles-Garay,
Duane Wessels and Suzanne Woolf for providing review and feedback. Duane Wessels, and Suzanne Woolf for providing review and feedback.
Authors' Addresses Authors' Addresses
Kim Davies Kim Davies
Internet Assigned Numbers Authority Internet Assigned Numbers Authority
PTI/ICANN PTI/ICANN
12025 Waterfront Drive 12025 Waterfront Drive
Los Angeles 90094 Los Angeles, CA 90094
United States of America United States of America
Email: kim.davies@iana.org Email: kim.davies@iana.org
Jari Arkko Jari Arkko
Ericsson Research Ericsson Research
02700 Kauniainen 02700 Kauniainen
Finland Finland
Email: jari.arkko@ericsson.com Email: jari.arkko@ericsson.com
 End of changes. 39 change blocks. 
101 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/