要約

  • RFC 3152はIP6.ARPAを選び、IABの指示に基づくIANAの委任と、IPv6アドレス配分に沿うRIRへの下位委任を求めた。個々の逆引きゾーンやPTRまで自動的に作ったわけではない。
  • IP6.INTの非推奨化は、新規実装で使わず秩序立てて廃止するという意味だった。2005年の追加措置は、2001年の合意と運用上の終了が別の時刻だったことを示す。
  • RFC状態、親子委任、PTR、実際の問い合わせ接尾辞、キャッシュ、DNS応答、検証、アプリケーション判断を分離しなければならない。逆引き名はホストの身分証明ではない。

移行の最初の成果は「同じ行き先」だった

IPv6にも、アドレスからDNS名を探すための階層が必要だった。初期の文書はIP6.INTを参照したが、IABは技術基盤の識別空間を.ARPAへ集めようとしていた。RFC 3152が提供したのは、新しい逆引き機能そのものより、全員が向かう根の選択だった。

文書は五つの既存RFCにあるIP6.INT参照を更新し、IABの指示に従ってIANAがIP6.ARPAを委任するよう求めた。下位の名前はIPv6アドレス空間の割り当てに合わせ、地域インターネットレジストリへ委任される。

それでも、発行日に全ソフトウェアが変わったとは書かなかった。「非推奨」は新規実装には適切でなく、旧方式を秩序立てて段階的に廃止するという定義だった。古いライブラリ、二重運用中のゾーン、残存キャッシュは移行期間に存在できた。

最小限の合意は世界同時更新を要求しない。だから採用できる。しかし、標準の方向と観測された動作を同じ列に記録してはならない。

委任の階段には別々の管理者がいた

IP6.ARPAの委任は一つのスイッチではない。IETFが技術規約を定め、IABが基盤名前空間の方針を示し、IANAが上位を運用する。RIRはアドレス配分に対応する部分を受け取り、資源保有者とDNS運用者がさらに下位のゾーンとPTRを管理する。

RFC 3172は.ARPAを用途限定の基盤ドメインと説明し、その運用をインターネットサービスに不可欠なものと位置づけた。IP6.ARPAはIANAからRIRへ、番号資源と対応する階層で下りていく。

だが、アドレス割り当て記録は逆引き委任の記録ではない。親のreferralがあっても子がlameなら到達しない。子が権威応答してもPTRがなければ名前は返らない。PTRがあっても、その名前のAAAAが元のアドレスを返すとは限らない。

組織の階層とDNSの観測は関連するが、代用できない。それぞれの時点、管理者、データを残す必要がある。

正しいQNAMEは結果の入口にすぎない

RFC 3596は後に安定した方式を統合した。IPv6アドレスを16進ニブルに分け、逆順で一文字ずつラベル化し、IP6.ARPAを付ける。ここまで正しければ、問い合わせキーの生成は証明できる。

その先ではreferral、NXDOMAIN、SERVFAIL、タイムアウト、未検証の回答、検証済み回答、キャッシュ済み回答があり得る。これらは一つのresolvedフラグでは表せない。

PTRはゾーン運用者が公開するDNSデータである。端末の所有者、到達性、利用許可を証明しない。正引きとの一致も自動ではない。ログ表示に使うアプリケーションと、アクセス判定に使うアプリケーションではリスクが異なる。

新しい木を問い合わせるクライアント側と、委任やレコードを整える権威側は独立に進む。片方だけが完了している状態も、移行の現実である。

二重運用は切断を避け、出所を見えにくくした

新旧の木を一時的に併存させれば、全世界同日のリリースを避けられる。新しい実装はIP6.ARPAへ進み、古い実装はIP6.INTを使い続けられる。運用者も段階的にデータを移せる。

ただし、黙ったfallbackは成功の出所を隠す。画面に名前が出ても、どちらの木が答えたか分からない。両方の木が答えても内容が同じとは限らない。新しい委任を追加した後も、古い負のキャッシュが不在を演出できる。

監査には正確なQNAME、リゾルバとバージョン、キャッシュ命中、fallback、referral列、権威サーバ、RCODE、RRset、TTL、検証状態が必要だ。「逆引き成功」だけでは、実行された経路を再現できない。

後年の文書はこの時間差を裏づける。RFC 3596は2003年に変更を標準トラックのIPv6 DNS仕様へ統合した。RFC 4159は2005年9月1日以降、標準準拠実装がIP6.INTを使わないよう勧告し、RIRに登録支援終了の日程を地域と調整するよう求めた。2001年の選択だけで撤収は終わっていなかった。

RFCの廃止は成果の廃止ではなかった

RFC 3596がRFC 3152をobsoleteにしたことは、IP6.ARPAを捨てたという意味ではない。3152の変更を、より包括的なIPv6 DNS仕様へ取り込んだのである。

周辺も別々に整備された。RFC 3363はA6とBitstring LabelをExperimentalへ移し、AAAAを推奨した。RFC 5855は後にIPv4・IPv6逆引きゾーンのネームサーバへ安定した命名を与えた。RFC 9121はIP6.INTを.INTから除かれた歴史的基盤ドメインとして整理した。

レコード方式、名前空間の根、サーバ運用、旧ドメイン撤去は異なる変更面である。一度の改名として描けば、何がいつ変わったかを失う。

「新しい脅威ではない」は安全宣言ではない

RFC 3152は、IPv4の住所から名前への対応がspoofingに悪用された事実を認めたうえで、IP6.ARPA委任は新しい脅威を作らないと述べた。これは根を移す行為の範囲を語っただけで、PTRを認証情報にしたのではない。

RFC 3596も、適切な安全技術なしのDNS情報は安全でないと明記した。DNSSECが成功すれば、信頼連鎖に対するDNSデータの真正性は確認できる。それでも名前の社会的意味、端末の現在の管理者、アプリケーション上の権限までは証明しない。

検証の有無、署名ゾーン、正引き照合、表示用途か認可用途かを別々に記録すべきだ。読みやすい逆引き名に、資格情報の権限を移してはならない。

実行された問い合わせが移行の現在地を示した

親子委任とPTRが正しい場面を考える。古いプログラムはIP6.INTを問い合わせて失敗する。別のプログラムは新しい木を選ぶが、ゾーン作成前の負キャッシュを持つ。三つ目だけが新しい回答を得る。標準状態は同じでも、現実は三通りだ。

Running-Code Primacyは規範を否定しない。RFC 3152は正しい根と委任モデルを決める。実行記録は、実際の接尾辞、到達した権威、得たデータ、アプリケーションの結果を決める。

最小初期仕様は、共通の根、委任要求、配分に沿う階層、旧方式の非推奨化だけを共有した。原子的な世界更新を要求しなかったから、移行は進められた。その代わり、どの層も全体の完了を一人で宣言できない。

IP6.ARPAが正しく存在しながら、IP6.INTの最後の問い合わせがまだ残る。RFC 3152の歴史は、その二つが矛盾しないことを教えている。

情報源