Summary

  • RFC 5223 の DHCPv4 オプション 137 と DHCPv6 オプション 51 は、RFC 1035 形式で符号化した一つの LoST サーバー FQDN を渡す。その名前は DNS/U-NAPTR の入力であり、サーバーアドレス、認証済み権威、マッピング、緊急対応の完了ではない。
  • DHCP の来歴、名前の解析、DNS ビュー、U-NAPTR、選択 URI、LoST の身元、マッピング、下流結果を分離した発見経路の受領書が必要になる。

端末が受け取ったのは探索の開始位置

新しいネットワークに接続した端末は、DHCP で LoST オプションを要求する。応答には一つのドメインが入り、ラベル長も終端も正しい。構成処理は成功として終わる。

しかし、その成功が示すのは、解釈可能な名前が届いたことだけだ。誰がその名前空間を選ぶ権限を持つか、DNS がどのサービスを返すか、サービスの身元が正しいか、マッピングが新しいかは分からない。

RFC 5223 は DHCPv4 の 137 と DHCPv6 の 51 に、一つの FQDN を載せる。その FQDN を LoST と RFC 4848 の DNS/U-NAPTR 手続きへ入力する。IP アドレスや最終 URIを直接配る仕組みではない。小さな仕様上の区別が、責任範囲を明確にする。

正しい形式と正しい委任は別である

ドメインは RFC 1035 のラベル形式を使い、全体は 255 オクテット以内、一つのルートラベルで終わる必要がある。この検査で、壊れたデータや複数名を拒否できる。

だが、形式検査では DHCP 応答の権限を確認できない。受け取った FQDN はリゾルバへ渡り、接続場所、キャッシュ、時刻、DNS ビューに応じた U-NAPTR 結果へ変換される。選ばれた URI の先で、初めて LoST サービスの身元を確認する。

その後の RFC 5222 マッピングにも、使用位置、情報源、期限、境界、返された宛先という独立した状態がある。宛先が正しくても、緊急応答者が応答した証明にはならない。各層は入力を変換するが、次の層の権威を作らない。

アクセス網は委任先を選んでいる

アクセス網は、自ら運用する LoST サーバーか、知っている第三者のサーバーのドメインを提示できる。この柔軟性はローカル構成に役立つ。同時に、端末が入る委任経路をアクセス網が選ぶことになる。

DHCP 運用者、ドメイン所有者、DNS 管理者、LoST 運用者、緊急サービスは別組織かもしれない。DHCP 設定を直せる者が DNS を直せるとは限らない。ドメインが同じまま U-NAPTR の委任先だけ変わる場合もある。

記録には、FQDN の承認者、ゾーン管理者、レコード発行者、期待するサービス身元、失効権限を残す。同じ利用者が異なるアクセス網で別のドメインを受け取る理由も説明する。「ローカル」は距離を表す語であって、全工程の権限を表す語ではない。

悪意ある選択は DNS より前に入る

RFC 5223 は、DHCP 応答を変更または挿入できる攻撃者が、端末を悪意ある LoST サーバーへ導くか、無効なアドレスを与え得ると述べる。出発点がすり替われば、その後の DNS 処理が正常でも正しい経路には戻らない。

一方、真正な DHCP 応答も、DNS やサービスを自動的に保証しない。DHCP の来歴、DNS の整合、U-NAPTR 解釈、サーバー認証、LoST 保護、マッピングの鮮度、下流到達性には個別の証拠が要る。

運用上の失敗も分ける。オプション欠落、形式不正、NAPTR なし、認証失敗、応答なし、マッピングなし、最終宛先に届かない状態は、それぞれ修復者が違う。単一の「発見失敗」にまとめれば、原因と権限が消える。

近いサーバーは、測定された可用性ではない

RFC は、端末に近い LoST サーバーが望ましく、災害時の断続的な接続で回復力に利点を持ち得ると説明する。これは設計理由であり、特定網の可用性や緊急応答結果の測定ではない。

近いサーバーが遠隔リゾルバや古い委任に依存することもある。アクセス事業者と別主体が運用していることもある。DHCP、DNS、認証、マッピング、下流通信を含む障害試験なしに、「ローカル発見」を回復力の数値へ置き換えることはできない。

意思決定者は、競合 DHCP、リゾルバ停止、期限切れレコード、サービス身元変更、ローカルインスタンス停止、手動設定へのフォールバックを実際に試した証拠を求めるべきだ。

証拠が示さないもの

資料は、オプション 137 または 51 の現在の普及を示さない。侵害された DHCP、偽 LoST サーバー、失敗した緊急要求、製品不具合も特定しない。RFC 3315 は当時の DHCPv6 参照で、後に RFC 8415 に置き換えられたが、それだけで現在の利用は分からない。

本稿は RFC 5222 のマッピング結果とサービス提供の境界も再利用しない。扱うのはその前段である。DHCP が渡す FQDN は探索入力であり、その先の権威と結果は各段階で立証する。

発見経路の受領書

接続網、DHCP 版、観測できるサーバー来歴、オプション番号、生データのハッシュ、解析結果、FQDN とルート、時刻とリース、リゾルバビュー、U-NAPTR、TTL、URI とアドレス、LoST 身元、要求と応答、マッピング時刻、下流結果を一つの記録へ結ぶ。

欠落、競合応答、不正ラベル、予期しないドメイン変更、DNS ビュー差、期限切れ、認証失敗、手動構成、到達不能も残す。それらが実際の発見範囲を示す。

Lu Heng の稼働事実と責任主体という考え方では、アクセス網は DHCP、ゾーン管理者は委任、LoST 運用者はサービス、アプリケーションは結果を証明する。一者の受領書に全員の権威を持たせてはならない。

Sources

追加記録

  1. RFC 5223 プレーンテキスト
  2. RFC 5223 情報ページ
  3. RFC 5223 Datatracker
  4. RFC 5223 正誤表