RFC 9120 - Nameservers for the Address and Routing Parameter Area ("arpa") Domain 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9120.html
タイトル : RFC 9120 - アドレスとルーティングパラメータ領域（ "ARPA"）ドメインのネームサーバー
翻訳編集 : 自動生成

[要約] RFC 9120は、"arpa"ドメインのネームサーバーに関する文書であり、インターネットの基盤となるアドレスとルーティングパラメータエリアの管理について定義しています。この文書は、インターネットの安定性と運用のための重要なガイドラインを提供し、特に技術者やシステム管理者がインターネットの基盤技術を理解し管理する際に利用されます。

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

アドレスとルーティングパラメータ領域（ "ARPA"）ドメインのネームサーバー

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.

このドキュメントでは、DNSルートゾーンと一緒にDNSの履歴操作からDNS内の「ARPA」トップレベルドメインの機能を分離するための運用方法へのリビジョンについて説明します。

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.

この文書はインターネットアーキテクチャボード（IAB）の積であり、IABが恒久的な記録を提供するために貴重な情報を表しています。ITインターネットアーキテクチャボード（IAB）のコンセンサスを表します。IABによる出版承認済みの文書は、いかなるレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。

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.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9120で取得できます。

著作権表示

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.

この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。

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

1. はじめに

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.

「ARPA」トップレベルドメイン[RFC3172]は、インターネット規格で定義された技術をサポートするための「インフラストラクチャドメイン」として指定されています。「ARPA」ドメインの下のゾーンは、IPアドレスなどのさまざまなマッピングをドメイン名とE.164番号にURIに提供します。また、住宅ネットワークで使用される非ユニークな名前である「home」などの特別な使用名も含まれています。

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.

歴史的に、「ARPA」ゾーンは、ほとんどすべてのルートネームサーバー（NSS）でホストされており、[RFC3172]は、ルートサーバーの運用上の要件がの運用要件に適用される「ARPA」ドメインが「ARPAのドメイン」を想定しています。"ARPA"サーバー "。今日まで、これは、ルートサーバーインフラストラクチャのサブセット上に「ARPA」ドメインを直接提供することによって実装されています。

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.

このルートネームサーバと「ARPA」NameServer操作のこのバンドルは、ゾーンの内容とそのインフラストラクチャの管理を抑制しました。その結果、「ARPA」ゾーンを含むIETFによって考慮されたいくつかの提案は、ルートゾーンのコンテンツの管理またはルートネームサーバの管理に関連する操作との競合の危険性があるために廃棄されています。

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.

この文書に記載されている分離は、現在の依存関係を排除し、各ゾーンの固有の要件に基づいてより調整された操作を可能にすることによって、編集をルートゾーンと「ARPA」ゾーンに同期させる操作上の影響を解決します。

2. Requirements for the "arpa" Zone

2. 「ARPA」ゾーンの要件

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].

「ARPA」ドメインは重要なインターネット操作で役割を果たし続け、この変更はドメインの[RFC3172]に記載されている操作要件の低下を提案しません。「ARPA」ドメインの将来の運用要件は、[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].

「ARPA」ゾーンの管理への変更は、「ARPA」ネームスペース内に委任されている他のゾーンの管理方法を変更しません。たとえば、「IP6.ARPA」は[RFC5855]に従って管理され続けるでしょう。

3. Transition Process

3. 遷移プロセス

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.

このプロセスは、「ARPA」ゾーンにとって権限があるサーバーに新しいホスト名を専用にしますが、最初は同じホストから「ARPA」ゾーンにサービスを提供します。

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.

完了したら、後続の移行段階には、新しいホストを使用して既存のルートNameServerホストを置き換えたり、「ARPA」ゾーンの編集と配布とを必ずしもルートゾーンに接続したりすることが含まれます。そのような変更がどのように実行され得るかに関する将来の管理に関する考慮事項は、この文書の範囲を超えています。

3.1. Dedicated Nameserver Hostnames

3.1. 専用ネームサーバーホスト名

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:

「ARPA」ゾーン[RFC5855]では、「ARPA」ゾーン[RFC5855]の「ARPA」ネームスペース自体の使用と一致しています。最初に次のように表示されます。

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

A.NS.ARPA B.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".

専用ホスト名「ARPA」ゾーンとルートゾーンのネームサーバの協調編集を必要とする論理的な依存関係を排除します。この遷移のこのコンポーネントでは、「ARPA」ネームサービス（つまりルートネームサーバー）を提供する基盤となるホストが変更される必要はありません。「ARPA」ゾーンは、「root-servers.net」内のそれぞれのホスト名ですでにサービスを提供している同じIPアドレスに最初にマッピングされます。

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.

これらのネームサーバーは完全に "ARPA"ゾーン内にあるため、ルートゾーン内の接着レコードが必要になります。これは現在の練習と一致しており、ルートゾーンへの運用上の変更を必要としません。

3.2. Separation of Infrastructure

3.2. インフラの分離

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.

ルートゾーンと共有されていないホスト名を使用するように「ARPA」ゾーンを最初に移行した後、基礎となるネームサービスは、ルートNameServerインスタンスのサブセットと直接整列しなくなるように進化すると予想されます。ルートネームサーバと「ARPA」ネームサーバとの間に共有インフラストラクチャがない場合、「ARPA」ゾーンのための将来の新しいアプリケーションが可能であり得る。

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].

その後のゾーンのネームサービスを提供する当事者への変更は、通常の管理責任と見なされ、[RFC3172]に従って実行されます。

3.3. Zone Administration

3.3. ゾーン政権

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.

信頼できる「ARPA」ネームサーバへの「ARPA」ゾーンファイルの公開は、現在ルートゾーンメンテナンス機能と並行して行われています。ルートネームサーバインフラストラクチャから「ARPA」インフラストラクチャを分離すると、「ARPA」ゾーンの公開は必ずしも技術的にリンクされているか、ルートゾーンの出版メカニズムに相互に関連する必要がなくなります。

3.4. Conclusion of Process

3.4. プロセスの終わり

Full technical separation of operations of the "arpa" zone and root zone minimally requires the following to be satisfied:

「ARPA」ゾーンとルートゾーンの操作の完全な技術的分離は、次のことを最小限に抑える必要があります。

* The "arpa" zone no longer shares any hostnames in its nameserver set with the root zone.

* 「ARPA」ゾーンは、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.

* 権威あるネームサービスを提供するホストは、ルートネームサーバと同じホストではなく、ルートサーバとのIPv4またはIPv6アドレスを共有しないため、どのように影響を与えずに一意の「ARPA」ゾーンの要件を展開できるように別々にプロビジョニングされています。ルートゾーンサービスが提供されています。

* 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.

* 「ARPA」ゾーンの編集および公開プロセスは、ルートゾーンプロセスとの共通の依存関係を削除し、「ARPA」ゾーンをルートゾーンと全く独立して完全にプロビジョニングできるようにします。

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.

このような分離は、根底にルートゾーンとルートサーバーの操作に影響を与える危険性なしに、「ARPA」ゾーンの新しい用途を可能にすることが最終的に求められています。この状態を達成することは、影響を最小限に抑えるためにかなりの調整を含む審議プロセスを必要とすることが認識されている。

4. IANA Considerations

4. IANAの考慮事項

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は、「NS.ARPA」の名前空間の作成を調整し、「root-servers.net」の中で文書化されている現代のルートサーバーのIPアドレスを反映したアドレスレコードをその初期状態として作成します。名前空間は、（空の非介護として）または運用上の要求に従って、専用の「NS.ARPA」ゾーンを確立することを通じて、「ARPA」ゾーン内（空の非介護者として）プロビジョニングすることができます。

IANA will initially migrate the 12 NS records for the "arpa" zone to point to their respective new entries in the "ns.arpa" domain.

IANAは最初に「ARPA」ゾーンの12 NSレコードを「NS.ARPA」ドメインのそれぞれの新しいエントリを指すように移行します。

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.

これらの行動が完了すると、IABとIANAは、「ARPA」ゾーンにサービスを提供するルートゾーンとルートサーバーのインフラストラクチャの依存を減らすかまたは排除するために、活動に関するすべての関連当事者と相談し、調整します。このような変更は[RFC3172]に準拠して行われ、重要なインフラストラクチャへの潜在的な影響を軽減するために、すべての十念注意と審議で行われます。

5. Security Considerations

5. セキュリティに関する考慮事項

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.

「ARPA」ゾーンのセキュリティは、これらの変更のいかなる側面によっても必ずしも影響を受けません。ゾーンの内容の管理（DNSSECを使用したゾーンに署名を含む）の管理に関連する堅牢な慣行、およびその分布は必要です。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[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>.

[RFC3172] Huston、G.、ED。、「アドレスおよびルーティングパラメータ領域ドメイン（「ARPA」）」、BCP 52、RFC 3172、DOI 10.17487 / RFC3172、2001年9月、<https：//www.rfc-editor.org/info/rfc3172>。

6.2. Informative References

6.2. 参考引用

[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>.

[RFC5855]能力、J.およびT.マンダン、「IPv4およびIPv6リバースゾーン用ネームサーバ」、BCP 155、RFC 5855、DOI 10.17487 / RFC5855、2010年5月、<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>.

[RFC7720]ブランチェット、M.およびL-j。LIMAN、「DNSルートネームサービスプロトコルと展開要件」、BCP 40、RFC 7720、DOI 10.17487 / RFC7720、2015年12月、<https：//www.rfc-editor.org/info/rfc7720>。

IAB Members at the Time of Approval

承認時のIABメンバー

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

Jari Arkko Deborah Brungard Ben Campbell Lars Eggert Wes Hardaker Cullen JenningsMirjaKühlewindZhenbin 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.

Alissa Cooper、Michelle Cotton、Lars-Johan Liman、Wes Sharkaker、Ted Hardie、Paul Hoffman、Paul Hoffman、Russ Oscar Robles-Garay、Duane Wesls、およびレビューとフィードバックを提供するためのSuzanne Woolf。

Authors' Addresses

著者の住所

Kim Davies Internet Assigned Numbers Authority PTI/ICANN 12025 Waterfront Drive Los Angeles, CA 90094 United States of America

Kim Daviesインターネット割り当て番号局PTI / ICANN 12025 Waterfront Drive Los Angeles、CA 90094アメリカ合衆国

   Email: kim.davies@iana.org

Jari Arkko Ericsson Research 02700 Kauniainen Finland

Jari Arkko Ericsson Research 02700 Kauniainenフィンランド

   Email: jari.arkko@ericsson.com