要約

  • RFC 3646 の Option 23 は再帰サーバーを優先順で示し、Option 24 は DNS 専用の検索リストを渡すが、どちらも端末での採用や利用を証明しない。
  • 値が一致しても DHCPv6 と RA の由来や寿命を統合してはならず、元の名前からアプリ結果までを別々に追跡すべきである。

有線から無線へ切り替えた直後を考える。設定画面には切替前と同じ IPv6 のリゾルバーが見える。これだけでは継続性を証明できない。以前の DHCPv6 値が残ったのか、新しい Reply が再提示したのか、RA の RDNSS が同じ値を支えたのか、それとも手動設定が自動設定を拒んだのか。表示値が一つでも、事実は複数ある。

RFC 3646 の OPTION_DNS_SERVERS はコード 23 で、IPv6 再帰ネームサーバーのアドレスをクライアントリゾルバーの優先順で並べる。OPTION_DOMAIN_LIST はコード 24 で、DNS によるホスト名解決の検索リストを指定し、他の名前解決方式には適用しない。テキスト版 は、両者を Solicit、Advertise、Request、Renew、Rebind、Information-Request、Reply に限定している。

優先順は利用実績ではない。一番目のアドレスが到達可能とは限らず、リゾルバーが実際に選んだとも限らない。キャッシュが応答すれば外部問い合わせさえ発生しない。したがって Option 23 の受信ログと、問い合わせ先・応答・アプリ利用を示すログは別々に必要になる。

検索リストでは、問い合わせ名そのものが変わる。RFC 1535 と RFC 1536 は暗黙リストの危険や、ドットを含む名前をまず完全修飾名として試す考え方を扱う。実務上は、アプリが渡した文字列、付加したサフィックスの順序、生成した候補名、採用した応答を保持しなければ、意図と結果を結び直せない。

DHCP 認証にも境界がある。RFC 3646 は、侵入者の DHCP サーバーによる問い合わせ先の誘導を避けるため、サーバー一覧のインストールや検索リストの受入れ前に認証を要求するよう勧める。しかし認証は設定源の判定であって、再帰サービスの健全性ではない。RFC 4033 の DNSSEC も、誤った検索ドメインで正当に署名されたレコードを排除できない。検証成功は、その問い合わせ名のデータを認証するだけで、利用者がその名を意図したとは証明しない。

さらに RFC 3646 は、手動設定済みの DNS パラメーターを DHCP で上書きしないよう勧める。パケットを受け取った事実と、ローカルポリシーが採用した事実は一致しない場合がある。調査には、手動設定の存在、優先規則、受入れ判断、インストール後の有効状態が要る。

RFC 8106 は RA で再帰サーバーと検索リストを配る別の経路を定義する。同じ値を重複として消せば、どの情報源の寿命によって有効だったのかが分からなくなる。値の集合ではなく、由来付きの状態として管理すべき理由である。

標準の系譜は範囲を示す。RFC 3315 は元の DHCPv6 基本仕様で、現在は RFC 8415 が置き換えている。RFC 8504 は IPv6 ノード要件を整理する。いずれも特定端末の瞬間的な状態を証明するものではない。

RFC 1034 の DNS 構造と RFC 1035 のメッセージ仕様は応答の解釈に必要である。RFC 3397 は DHCPv4 の検索リストとの比較材料になる。だが、実問い合わせの観測に代わる文書ではない。

IANA DHCPv6 パラメーター登録簿 は 23 と 24 を共通語として割り当てる。それは配布・採用・利用を証明しない。Datatracker、RFC Editor 情報、Errata、文書履歴も仕様の来歴を示す面であり、実装や運用の受領証ではない。

Heng Lu の稼働コード優先、最小初期仕様、現実の層という視点を当てると、役割分担が見える。標準は交換形式を揃える。端末はローカルな選択を行う。稼働状態と観測結果だけが、その選択の効果を裏づける。

必要な記録は、インターフェース、ネットワーク、DHCP サーバー識別と認証、オプションの生データ、手動設定の優先関係、採用判断、由来ごとの寿命、インストール状態、原入力、候補名、実選択サーバーとトランスポート、キャッシュ、応答、DNSSEC 判定、アプリ結果である。値の一致を理由に途中を省いてはならない。