要約

  • RFC 3172 は、基盤データへ至る前の DNS 依存を深くしないため .arpa をトップレベルに置き、その権威サーバーへ当時のルートサーバー運用要件を適用した。同じ要件は同じゾーンや同じ権限を意味しない。
  • 多くのルートサーバーが .arpa も提供していたが、文書はその配置が変わる可能性を明記し、.arpa と in-addr.arpa のデータをルートサーバーから移す作業を記録した。
  • 方針、管理上の依頼、親の委任、ゾーン生成、サーバー設定、到達可能な応答、検証、アプリケーション結果は別々の記録である。重要性は証拠水準を上げても、現任者を恒久化しない。

二回の問い合わせで届く場所

.arpa は一般的なホスト名を売るためのトップレベルドメインではない。アドレスや番号などのプロトコル値を階層的な DNS 名に変換し、サービス名や運用データを得るための基盤領域だった。

これを複数の組織ドメインの下へ置けば、対象データのサーバーを見つける前に多くの親へ依存する。RFC 3172 が説明したトップレベル配置では、ルートから .arpa の委任を得て、次に .arpa の権威サーバーへ進める。

短い経路は、ルートサーバーによる恒久ホスティングを要求しない。ルートは子の NS を示せばよく、子ゾーンを自ら配る必要はない。.arpa サーバーも厳格な要件を満たすからといってルートサーバーになるわけではない。

要件の共有と権限の共有は違う

RFC 3172 は .arpa の正確で効率的な運用を全利用者に関わる問題とし、RFC 2870 のルートサーバー要件を適用した。将来の改訂も引き継ぐ構成だった。専用ゾーン向けに弱い基準を作らず、既にある高い基準を使ったのである。

しかし、同じ耐障害性を求められる二つのサービスが同一主体になることはない。一台の機械に二つのゾーンが載っていても、運用者が双方の方針決定者になるわけではない。監視画面の同じ IP アドレスは、制度上の所有を示さない。

文書は当時の共用を率直に書いた。ルートゾーンの権威サーバーの多くが .arpa にも応答していた。それでも、その配置は将来変わる可能性が高いとした。さらに IAB、ICANN、IANA、地域レジストリが、ルートサーバーをルート専用にする勧告に沿って .arpa と in-addr.arpa のレコードを移す作業を進めていると説明した。

重要なサービスだからこそ、偶然の共用を設計原則に昇格させなかった。

名前を残して運用を移す

RFC 3152 の中心は IP6.INT から IP6.ARPA への名前空間移行だった。RFC 3172 が示す運用変更は別物である。利用者が見る .arpa は変えず、そのゾーンに権威応答するサーバー集合を変えられる。

名前が一定でも、切替は一操作ではない。親ゾーンが新しい NS と必要な glue を公開し、新サーバーが正しいゾーン世代を読み込み、異なるネットワークから到達でき、回答が一致し、キャッシュが旧委任を失い、依存アプリケーションが期待した結果を受ける必要がある。

親の変更だけでは実行を証明しない。新しい NS は設定不良かもしれない。古いサーバーは委任から外れた後も回答できる。SOA serial が同じでも一部地域から到達不能かもしれない。DNS 応答が正しくても、利用側の処理が成功したとは限らない。

RFC 3172 は個別切替の監査記録を提供しなかった。日時、パケット観測、停止、遅延改善、DNSSEC 結果を主張していない。そこから実行済みの物語を作るべきではない。

組織名より動詞を読む

IAB は ICANN と協力して文書上の管理責任を担い、IANA は RFC 2860 の関係の下で運用上の管理を行った。新しい .arpa 子ドメインは通常、IETF Standards Track 文書で定義され、IANA Considerations に名前、写像、管理規則、登録基準を記す。IESG の承認を経て IAB が IANA に依頼し、子の管理は適切なプロトコル管理主体へ委任できた。

決める、承認する、依頼する、親を編集する、子を管理する、サーバーで提供する、という動作は交換不能である。ひとつの組織欄に押し込めると、誰が何を検証可能にすべきか分からなくなる。

in-addr.arpa は IPv4 割当に沿い、ip6.arpa は IPv6 空間から IANA と地域レジストリを経て委任され、e164.arpa は電話番号と URI を結ぶ別の調整を持った。共通親は探索を統一したが、統治を単一化しなかった。

「移行完了」を組み立てる証拠

必要なのは、許可する仕様と版、承認と依頼、親ゾーン変更、NS/glue 世代、子ゾーン内容と SOA、各サーバーが実際に読んだ設定、定義した観測地点からの到達性と応答、検証状態、キャッシュ収束、利用サービスの結果を結べる記録である。

順序も重要だ。新サーバー準備より親更新が先なら障害になり得る。重複期間を長く残せば、保護策が不透明な二重経路へ変わる。古いサーバーへのトラフィックが一観測地点で消えても、世界的依存の消滅とは言えない。

後の RFC 9120 は .arpa ネームサーバー要件を更新し、RFC 7720 はルートサーバー要件を更新した。現在の IANA ページは今日の公開状態を示す。これらは2001年の記述を現在形で語らないために必要だが、移行履歴の空白を自動的に埋めない。

Lu Heng の現実層と稼働コードの議論は、後世の分析として明示して使う。制度上の任務、規範、台帳、委任、設定、観測、結果は相互参照できても同一ではない。守るべきは検証可能な調整機能であり、特定の守門者や機械ではない。この整理を RFC 著者や関係機関の主張として扱わない。

出典と限界

証拠は2026年10月2日、上海時間で凍結した。RFC 3172 の設計、2001年に記録された配置、その変更見込み、後続要件は確認できる。特定の切替日、障害、性能改善、DNSSEC 結果、運用者評価、完全な歴史トポロジー、アプリケーション成果は確認できない。