Nameservers for the Address and Routing Parameter Area ("arpa") DomainInternet Assigned Numbers AuthorityPTI/ICANN12025 Waterfront DriveLos Angeles90094United States of Americakim.davies@iana.orgEricsson Research02700 KauniainenFinlandjari.arkko@ericsson.comInternet-DraftThis 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.The “arpa” top-level domain 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 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.The “arpa” domain continues to play a role in critical Internet
operations, and this change does not propose weakening operational
requirements described in for the domain. Future operational
requirements for the “arpa” domain shall consider strong baseline requirements, such
as those documented in .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.Consistent with the use of the “arpa” namespace itself to host name
servers for other delegations in the “arpa” zone (), this
document specifies a new namespace of “ns.arpa”, with the
nameserver set to be labelled as follows: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.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 .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.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.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 and shall
be conducted with all due care and deliberation to mitigate potential
impacts on critical infrastructure.Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Nameservers for IPv4 and IPv6 Reverse ZonesThis document specifies a stable naming scheme for the nameservers that serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS. These zones contain data that facilitate reverse mapping (address to name). This memo documents an Internet Best Current Practice.DNS Root Name Service Protocol and Deployment RequirementsThe DNS root name service is a critical part of the Internet architecture. The protocol and deployment requirements for the DNS root name service are defined in this document. Operational requirements are out of scope.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?Thank you Michelle Cotton, Ted Hardie, Paul Hoffman, Russ Housley, Duane
Wessels and Suzanne Woolf for initial feedback.