Nameservers for the Address and Routing Parameter Area ("arpa") Domain
draft-iana-arpa-authoritative-servers-00

Abstract

This document describes revisions to operational practices to separate function of the “arpa” top-level domain in the DNS from its historical operation alongside the DNS root zone.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 10, 2020.

Copyright Notice

Copyright (c) 2020 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 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

• 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. References
• 5.1. Normative References
• 5.2. Informative References
• Appendix A. Open Issues
• 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 non-unique name used in residential home networks.

Historically, the “arpa” zone has been hosted on almost all of the root name servers, 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 server and “arpa” server operations has entwined management of the zones contents and their infrastructure. As a result, some proposals under consideration by the IETF involving the “arpa” zone have been discarded due to the risk of conflict with root operations.

The separation described in this document resolves operational impacts of synchronizing edits to the root zone and the “arpa” zone, 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 shall consider strong baseline requirements, such as those documented in [RFC7720].

3. Transition Process

The process will dedicate new hostnames to the servers authoritative for the “arpa” zone, but will initially serve the “arpa” zone from the same hosts.

Once completed, subsequent transitional phases would include using new hosts to replace or augment the existing root server hosts, and separation of the editing and distribution of the “arpa” zone from necessarily being connected to the root zone. Any 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 name servers for other delegations in the “arpa” zone ([RFC5855]), this document specifies a new namespace of “ns.arpa”, with the nameserver set to be labelled as follows:

   a.ns.arpa
   b.ns.arpa
   c.ns.arpa
   ...

This eliminates a logical dependency that requires the coordinated editing of the “arpa” zone and the root zone. This component of this transition does not require the underlying hosts that provide “arpa” name service (that is, the root servers) be altered. The “arpa” zone will initially map the new hostnames to to the same IP addresses that already provide service under the respective hostnames within root-servers.net.

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 to a subset of root server instances. With no shared infrastructure between the root servers and the “arpa” servers, future novel applications for the “arpa” zone may be possible.

Any subsequent changes to the parties providing name service for the zone is considered a normal management responsibility associated with zone management, and would be performed in accordance with [RFC3172].

3.3. Zone administration

Publication of the “arpa” zone file to the authoritative “arpa” name servers is currently undertaken alongside the root zone maintenance functions. Upon the separation of the “arpa” infrastructure from the root server infrastructure, publication of the “arpa” zone no longer necessarily needs to be technically linked or inter-related to the root zone publication mechanisms.

3.4. Conclusion of process

Full technical separation of “arpa” operations from root operations minimally requires the following to be satisfied:

• The “arpa” zone no longer shares any hostnames in its NS-set with the root zone;
• The hosts that provide authoritative name service are not the same hosts as the root servers, do not share any IPv4 or IPv6 addresses with the root servers, and are sufficiently separately provisioned 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 has any common dependencies with the root zone process removed, 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 inadvertantly 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

The IANA shall coordinate the creation of a new “ns.arpa” zone 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 IANA will initially migrate the 12 NS records for the “arpa” zone to point to their respective new entries in the “ns.arpa” zone.

Subsequently, the IAB and IANA will consult and coordinate with all relevant parties on activity to reduce or eliminate reliance upon root zone and root server infrastructure for 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. References

5.1. Normative References

5.2. Informative References

Appendix A. Open Issues

• A preference has been expressed for non-.arpa hostnames. Is it better that the nameserver hostnames are in-bailiwick in .arpa or does that provide no benefit?
• Should the name servers stick to the same letter-based nomenclature as the root zone? Some operators have expressed a strong desire to move away from the letters for the root zone.
• Should the hostname change be staggered or can it be done in one action?

Acknowledgments

Thank you Michelle Cotton, Ted Hardie, Paul Hoffman, Russ Housley, Duane Wessels and Suzanne Woolf for initial feedback.

Authors' Addresses