| RFC 9120 | Nameservers for the .arpa Domain | October 2021 |
| Davies & Arkko | Informational | [Page] |
This document describes revisions to operational practices to separate the function of the "arpa" top-level domain in the DNS from its historicaloperation alongside the DNS root zone.¶
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 athttps://www.rfc-editor.org/info/rfc9120.¶
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.¶
The "arpa" top-level domain[RFC3172] is designated as an"infrastructure domain" to support techniques defined by Internetstandards. Zones under the "arpa" domain provide various mappings, suchas IP addresses to domain names and E.164 numbers to URIs. It alsocontains 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 theroot nameservers (NSs), and[RFC3172] envisages the "arpa" domain to be"sufficiently critical that the operational requirements for the rootservers apply to the operational requirements of the "arpa" servers". Todate, this has been implemented by serving the "arpa" domain directly ona subset of the root server infrastructure.¶
This bundling of root nameserver and "arpa" nameserver operations has entwinedmanagement of the zones' contents and their infrastructures. As a result,some proposals under consideration by the IETF involving the "arpa" zonehave been discarded due to the risk of conflict with operations associatedwith managing the content of the root zone or administering the rootnameservers.¶
The separation described in this document resolves the operational impactsof synchronizing edits to the root zone and the "arpa" zone byeliminating the current dependency and allowing more tailored operationsbased on the unique requirements of each zone.¶
The "arpa" domain continues to play a role in critical Internetoperations, and this change does not propose weakening operationalrequirements described in[RFC3172] for the domain. Future operationalrequirements for the "arpa" domain are encouraged to follow strongbaseline requirements such as those documented in[RFC7720].¶
Changes to the administration of the "arpa" zone do not alter themanagement practices of other zones delegated within the "arpa"namespace. For example, "ip6.arpa" would continue to be managed inaccordance with[RFC5855].¶
The process will dedicate new hostnames to the servers that are authoritative forthe "arpa" zone, but it will initially serve the "arpa" zone from the samehosts.¶
Once completed, subsequent transitional phases could include usingnew hosts to replace or augment the existing root nameserver hosts andseparating the editing and distribution of the "arpa" zone fromnecessarily being connected to the root zone. Any future managementconsiderations regarding how such changes may be performed are beyondthe scope of this document.¶
Consistent with the use of the "arpa" namespace itself to host nameservers for other delegations in the "arpa" zone[RFC5855], thisdocument specifies a new namespace of "ns.arpa", with thenameserver 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 thecoordinated editing of the nameservers for the "arpa" zone and the rootzone. This component of this transition does not require that the underlyinghosts that provide "arpa" name service (that is, the root nameservers) bealtered. The "arpa" zone will initially map the new hostnames to thesame IP addresses that already provide service under the respectivehostnames within "root-servers.net".¶
Because these nameservers are completely within the "arpa" zone, theywill require glue records in the root zone. This is consistent withcurrent practice and requires no operational changes to the root zone.¶
After initially migrating the "arpa" zone to use hostnames that are not sharedwith the root zone, the underlying name service is expected to evolve such thatit no longer directly aligns with a subset of root nameserver instances. With noshared infrastructure between the root nameservers and the "arpa" nameservers, futurenovel applications for the "arpa" zone may be possible.¶
Any subsequent change to the parties providing name service for thezone is considered a normal management responsibility and would beperformed in accordance with[RFC3172].¶
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 nameserverinfrastructure, publication of the "arpa" zone no longer necessarily needsto be technically linked or interrelated to the root zone publicationmechanisms.¶
Full technical separation of operations of the "arpa" zone and root zone minimally requires the following to be satisfied:¶
Such separation is ultimately sought to allow for novel uses ofthe "arpa" zone without the risk of inadvertently impacting root zone and rootserver operations. It is recognized that achieving this state requires adeliberative process involving significant coordination to ensure impactsare minimized.¶
IANA shall coordinate the creation of the "ns.arpa" namespace andpopulate it with address records that reflect the IP addresses of thecontemporary root servers documented within "root-servers.net" as itsinitial state. The namespace may be provisioned either directly withinthe "arpa" zone (as an empty nonterminal) or through establishinga 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 consultand coordinate with all relevant parties on activity to reduceor eliminate reliance upon the root zone and root server infrastructure serving the "arpa" zone. Suchchanges will be performed in compliance with[RFC3172] and shall beconducted with all due care and deliberation to mitigate potentialimpacts on critical infrastructure.¶
The security of the "arpa" zone is not necessarily impacted by anyaspects of these changes. Robust practices associated with administeringthe content of the zone (including signing the zone with DNSSEC) as well as its distribution will continue to be necessary.¶
Internet Architecture Board members at the time this document wasapproved for publication were:¶
Thank youAlissa Cooper,Michelle Cotton,Lars-Johan Liman,Wes Hardaker,Ted Hardie,Paul Hoffman,Russ Housley,Oscar Robles-Garay,Duane Wessels, andSuzanne Woolf for providing review and feedback.¶