要約

  • A6 は別々に管理される DNS 断片から IPv6 アドレスを合成できたが、段数ごとに問い合わせ、キャッシュ状態、失敗機会、管理依存を増やした。
  • RFC 3363 は A6 とバイナリラベルを Proposed Standard から Experimental へ移し、本番では AAAA を優先した。文書状態の変更は配備済みシステムの即時変更ではない。

A6 は、番号変更の痛みを DNS の合成で減らそうとした。RFC 2874 では、ホスト側が安定した部分を保持し、上位の管理者が接頭辞を管理できる。接頭辞が変わっても、すべての末端レコードを書き換えずに済む場合があった。

しかし、答えを作るには各断片が必要だった。リゾルバは接頭辞名を追い、別の権威サーバへ問い合わせ、さらに次の段へ進むことがある。各段は異なる TTL、キャッシュ、管理者、障害を持つ。一つ欠ければ完全なアドレスにならない。

2002 年の RFC 3363 は、この依存を標準状態へ反映した。情報文書として RFC 2673 と RFC 2874 を更新し、両者を Proposed Standard から Experimental に移した。DNSEXT と NGTRANS の議論から、AAAA は本番向きであり、A6 の特性は興味深いが、利益が費用と危険を上回るか不明だという判断を記録した。

これは A6 の価値を否定する文書ではない。対になる RFC 3364 は、予告なく変わる接頭辞を検索時に表現できる点を詳しく論じた。AAAA を自動生成する方法は、依存情報をプロビジョニングへ移す。柔軟性の費用が消えるわけではない。

RFC 3363 は、キャッシュがなければ N 段の解決時間がおおむね N に比例し、失敗確率も段数とともに増えると推論した。これは世界規模の測定結果ではなく、直列依存から導く運用上の評価である。

組織境界はさらに重い。魅力的な構成の一部は、ゾーン外や別組織の接頭辞を参照した。各管理者が自分の断片を正しく保っていても、連絡先の消失、古い委任、異なる更新時刻によって全体は壊れる。キャッシュの時間差で観測者ごとに別のアドレスが組み上がる可能性もある。

AAAA は完全な 128 ビットを一つのレコードへ置く。番号変更時の更新量は増え得るが、検索依存は明示的に短い。RFC 3363 は RFC 1886 を標準トラックに残すよう勧告し、RFC 3596 が後に AAAA と IP6.ARPA を整理した。

逆引きのバイナリラベルも実験へ戻された。RFC 2673 は RFC 1035 以来初の新しいラベル型だったが、未対応サーバは問い合わせを不正形式として拒否し得た。想定される委任は十六進テキストで表現できた。逆引きルート自体は RFC 3152 の範囲である。

これは成果の削除ではなく、互換性集合の縮小だった。実験として保存しつつ、証拠の乏しい新規性を本番の前提から外した。

文書状態、実装、ゾーン、解決、サービスは別々の証拠である。Experimental への変更はコードを消さない。対応コードは公開レコードを証明しない。完全な DNS 回答も到達可能なサービスを証明しない。RFC 4472 は、AAAA の下でも残る IPv6 DNS 運用問題を後に列挙した。

RFC 3597 が扱う未知 RR 型の汎用搬送と、新しいラベル構文の解析も同一ではない。データを意味不明のまま保持できても、名前を解析できない場合がある。

現在の IANA 登録は識別子と状態の保管証拠であり、過去の導入台数ではない。本稿は Lu Heng の「Minimum Initial Specification」を共通層の厚さを考えるレンズとして、「On Reality Layers」を文書、コード、ゾーン、キャッシュ、結果を分けるレンズとして明示的に用いる。

合成可能性は自由を生む。同時に、各断片を必要な時刻に利用可能にする責任も増やす。RFC 3363 はその費用を本番の既定値から外した。

出典