arpa nameservers: Nameservers for the Address and Routing Parameter Area ("arpa") Domain
How the arpa domain gets its own nameserver names, separate from the DNS root servers.
Davies, K. and J. Arkko, "Nameservers for the Address and Routing Parameter Area ("arpa") Domain", RFC 9120, DOI 10.17487/RFC9120, October 2021, <https://www.rfc-editor.org/info/rfc9120>.
@misc{rfc9120,
series = {Request for Comments},
number = 9120,
howpublished = {RFC 9120},
publisher = {RFC Editor},
doi = {10.17487/RFC9120},
url = {https://www.rfc-editor.org/info/rfc9120},
author = {K. Davies and J. Arkko},
title = {{Nameservers for the Address and Routing Parameter Area ("arpa") Domain}},
pagetotal = 7,
year = 2021,
month = oct,
} RFC text
Contents
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
AI ELI5
On this page
§1Why arpa Needs Separating
The arpa top-level domain is designated an infrastructure domain that supports techniques defined by Internet standards. Zones under it provide mappings such as IP addresses to domain names and E.164 numbers to URIs, and it also holds special-use names such as home.
Historically, arpa has been served on almost all of the root nameservers, and RFC 3172 envisaged that the operational requirements for the root servers would apply to the arpa servers. This bundling entwined the management of the two zones, and some IETF proposals involving arpa were discarded because of the risk of conflict with operations on the root zone or root servers.
Two things that live in the same building cannot change their doors or walls without bothering each other. Moving them apart lets each one change what it needs.
§2Requirements That Stay the Same
This change does not weaken the operational requirements of RFC 3172. Future requirements for arpa are encouraged to follow strong baselines such as those in RFC 7720.
Other zones delegated within arpa are untouched. For example, ip6.arpa continues to be managed under RFC 5855.
The rules for keeping arpa safe and reliable stay just as strict. Only where it lives changes.
§3The Transition Process
First, new hostnames are dedicated to the arpa servers: a new namespace ns.arpa, with the nameserver set labelled a.ns.arpa, b.ns.arpa, c.ns.arpa and so on. The zone initially maps these names to the same IP addresses that already serve it under root-servers.net, so the underlying hosts do not change. Because these nameservers sit completely within arpa, they need glue records in the root zone, which matches current practice.
Later phases could use new hosts to replace or augment the root nameserver hosts, and separate the editing and distribution of the arpa zone from the root zone. Any change of parties providing the service is treated as normal management under RFC 3172.
Step one is only a change of names on the mailboxes. The same mail carriers deliver to the same addresses, so nothing breaks while the move is prepared.
§3.4When Separation Is Complete
Full technical separation minimally requires three things:
- The arpa zone shares no hostnames in its nameserver set with the root zone.
- The hosts serving arpa are not the root nameservers, share no IPv4 or IPv6 addresses with them, and are provisioned separately.
- The editorial and publication process for arpa has no common dependencies with the root zone process.
The goal is to allow novel uses of arpa without the risk of impacting root zone and root server operations. The RFC recognizes that this needs a deliberative process with significant coordination.
Moving is finished when arpa has its own names, its own machines and its own way of publishing changes.
- Own hostnamesNo shared names in the nameserver set.
- Own hostsDifferent machines and no shared IPv4 or IPv6 addresses.
- Own publicationNo common dependency with the root zone process.
§4IANA Actions and Security
IANA is to coordinate creation of the ns.arpa namespace and fill it with address records matching the contemporary root servers in root-servers.net. It may be set up directly in the arpa zone as an empty nonterminal or as a dedicated ns.arpa zone. IANA will initially migrate the 12 NS records for the arpa zone to the new entries. Afterwards the IAB and IANA will consult with relevant parties on reducing reliance on the root zone and root servers.
On security, the RFC says the security of the arpa zone is not necessarily affected by these changes, and that robust practices for administering and distributing the zone, including signing it with DNSSEC, remain necessary.
IANA is asked to set up the new names and copy the old addresses into them. Keeping the zone signed and well looked after stays important.