要約
- DHCPv4の
OPTION_V4_LOSTは137番、DHCPv6のOPTION_V6_LOSTは51番であり、どちらもDNS形式のFQDNを一つだけ格納する。 - 受け取った名前はU-NAPTR/DNS探索への入力にすぎない。アドレス選択、到達性、TLSサービス識別、LoST応答、写像の適合性は後続の別判断である。
- 監査で重要なのは「見つかった」という結論より、どのネットワークが何を渡し、端末がどの検証を経て何を選んだかという連結可能な記録である。
根ラベルまで読めても、相手はまだいない
実在事故ではなく、検証用に組み立てた時系列を考える。08:14:00に端末がアクセス網へ接続する。08:14:01、DHCPACKに137番オプションが入り、lost.access.exampleへ正常に復号される。末尾には規定どおり一つの根ラベルがある。08:14:02、監視画面は「LoST discovery OK」と表示する。
だがログにはU-NAPTR応答がない。DNSアドレスも、選択した転送方式も、TLS相手のサービス識別結果もない。LoST要求は送られておらず、写像も連絡先URIも得ていない。呼が成立したかどうかを語る段階にはなお遠い。
RFC 5223は、この早合点を要求していない。アクセス網がLoSTサーバーを運用する場合、または第三者のサービスを知る場合に、DHCPでドメイン名を端末へ与えられる。その名をLoSTのDNS探索へ投入する。規格が作るのは境界の明確な引き渡しであり、包括的な信任ではない。
したがって最初の成功は「DHCP値を受領し、構文を解釈した」である。「権威あるLoSTサービスを発見した」ではない。
単一FQDNという設計を勝手に広げない
IPv4ではコード137、IPv6ではコード51を使う。名前はDNSラベルの長さと値を並べ、完全修飾名として一つだけ格納する。クライアントは各DHCP方式のオプション要求で取得を求められる。
このフィールドはIPアドレスではなく、最終URIでもない。複数サーバーの優先順位表でもない。IPv6図のキャプションにListという語があっても、本文は単一ドメイン名を明記している。実装が独自のリスト意味論を読み込めば、規格外のフェイルオーバー方針が証拠なしに生まれる。
保存すべき最小単位は、DHCPトランザクション、オプションコード、長さ、原バイト列、復号FQDN、構文判定である。後からDNSで得たIPをDHCP受信時の値として記録してはならない。時間の異なる判断を一つのイベントへ上書きすると、どこで選択が変わったかが消える。
コードポイント登録も権威証明ではない。機械同士が137番の意味に合意できるだけで、137番を付けた全メッセージの送り主を正当化するわけではない。
DHCPの正しさは接続文脈に束縛される
RFC 2131はDHCPv4のサーバー選択、ACK、設定値、リースを扱い、RFC 8415は現行DHCPv6の基礎を定める。ここで得られる証拠は、ある接続状況である設定経路が何を返したかである。
DHCPサーバー識別子は設定交換の参加者を示す。それだけで、FQDN先のLoST運用者と同一であることや、地理的管轄の権威を示さない。RFC 3046のリレー情報はアクセス経路を説明できるが、最終サービスの資格証明にはならない。
端末がWi-Fiからモバイル網へ移ると、古い名前の意味は変わり得る。再接続、Renew、Rebind、インターフェース切替のどれで再発見するのかを、実装は可視化しなければならない。アプリが最後のFQDNだけを永続保存すれば、ローカルな設定がいつの間にか端末全体の恒久方針になる。
「ネットワークが教えた」という記録には、どのインターフェース、管理領域、サーバー、リレー、時刻、リース状態だったかが必要である。主語と時刻のない受動態は、監査証拠にならない。
偽サーバーへの誘導は規格自身が警告する
RFC 5223は、DHCP応答を改変または挿入できる攻撃者が、クライアントを攻撃者管理下のLoSTサーバーや無効アドレスへ向けられると明示する。RFC 5069は緊急呼の標識と写像に関する脅威を整理している。
RFC 3118はDHCPメッセージ認証とリプレイ対策を規定する。ここから導けるのは「起源・完全性・鮮度を別に確認する必要がある」という設計上の事実であり、「現場では常に認証済み」という運用事実ではない。監査票には実際の検証結果を置くべきである。
認証済みDHCPでも、古い値や誤設定を返す可能性は残る。アクセス設定を提供する正当性と、LoST写像を決定する正当性は別である。正しい話者であることは、その話者が後続全システムの権限を持つことを意味しない。
Heng Luのrunning-codeの考え方に従えば、権威は実行された局所判断に結びつく。DHCPクライアントは受け入れた入力を証明できる。DNS、TLS、LoST、応答機関の判断まで代弁することはできない。
名前解決の各段階を残す
FQDNはRFC 5222の探索処理へ渡され、U-NAPTRによるサービス選択、DNS解決、アドレス選択、接続が続く。正しい名前でも適切なサービスレコードがないことはある。DNSがタイムアウトし、アドレスが到達不能になり、相手の識別子が期待と一致しないこともある。
RFC 8446はTLS通信を保護し、RFC 9525はサービス識別の検証を扱う。暗号化された接続というだけでは不十分である。誤って選んだ相手との通信も暗号化できる。
U-NAPTRの問い合わせと選択、DNS応答とTTL、検証状態、候補アドレス、実際の接続先、サービス識別結果を別々に記録する。これにより「DHCPは成功、DNSに該当サービスなし」と具体的に言える。
RFC 8917はLoST検証サービスに別のS-NAPTRタグを与える。役割を区別できることは、役割の名前と実行結果が別だという証拠でもある。
LoST応答はさらに下流にある
正しい相手へ接続した後も、LoST要求の送信と応答解釈が必要である。エラー、警告、リダイレクト、写像にはそれぞれ状態があり、写像には出所、更新時刻、期限、境界がある。
既存のRFC 5222記事は、その写像が呼の成立や応答を証明しないことを扱う。本稿の境界は一つ上流である。DHCPの名前は、まだ受け取っていない写像の正しさを先取りできない。
RFC 6739の同期・署名はバックエンド写像の由来を強化するが、端末のDHCP応答やDNSビューを遡って認証しない。RFC 6881が示す広い緊急通信の流れでも、設定、探索、写像、シグナリング、応答は固有の結果を持つ。
証拠は細く、接続可能に
接続文脈、DHCP取引、サーバー・リレー、メッセージ保護、原オプション、FQDN、リースと失効判断、U-NAPTR、DNS、TLS識別、LoST応答、写像適合性、セッション、応答結果を順に結ぶ。どこかが失敗しても、上流で確定した狭い事実は残る。
大画面には要約を表示してよい。しかし、要約から原証拠へ戻れない設計は、簡潔なのではなく不可逆である。
情報源
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加