要約

  • RFC 3397 は順序付き DNS ドメイン検索リストを DHCP オプション119に割り当てた。クライアントは RFC 3396 に従って断片を先に連結し、その完全な集合内で RFC 1035 の圧縮ポインターを解釈しなければならなかった。
  • 検索リストは DNSSEC より前に作用した。受理された悪意ある接尾辞が別の FQDN を構成し、そのドメインの運用者が正当に署名したレコードを返せば、利用者の意図しない問いに対する本物の応答が成立した。

myhost という短い入力だけでは、一意な DNS 問い合わせにならない。アプリケーションからネットワークへ届くまでに、接尾辞を選び、完全修飾名を作り、候補を並べる必要がある。RFC 3397 は、その選択肢を DHCP サーバーがクライアントへ渡す形式を定めた。

文書は2002年11月に標準化過程の RFC として公開され、Domain Search にオプションコード119を割り当てた。対象は DNS に限られる。異なる名前解決方式を選択したり順位づけたりするものではなく、その役割は RFC 2937 の別のオプションに属した。119が運ぶのは DNS 内で短い名前を補うドメイン列である。

値は単純な文字列一覧ではなかった。Searchstring は RFC 1035 のラベル形式でドメイン名を連結し、名前圧縮を許した。既出の完全名や接尾辞は、2オクテットのポインターで以前の位置を参照できる。複数の候補が apple.com. で終わるなら、同じラベル列を繰り返さずに済む。

ポインターの座標系は局所的だった。オフセットはオプションのデータ先頭から数え、コードと長さのオクテットを含まない。外部の DNS 名や別パケットへの参照ではなく、一つの論理的データ値の中にある過去の位置を指す。

ところが、その論理値は物理的には分割され得た。RFC 3397 は RFC 3396 の連結規則を用いる。同じ119の複数インスタンスが届けば、受信側はデータ部分をすべて一つにしてから意味を読む。その後に初めて RFC 1035 ポインターをたどる。したがって参照先が断片境界の向こう側にあっても正しい。

文書の例では eng.apple.com. と marketing.apple.com. が三つのインスタンスへ分かれる。後者の末尾の C004 は、集合のオフセット4、すなわち apple.com. の開始位置を指した。各断片を独立したリストとして即座に読む実装には、この座標は成立しない。DHCP の再構成は DNS の展開より先でなければならなかった。

終端規則は推測を禁じた。各検索ドメインは長さゼロのルートラベル、または有効な2オクテットポインターで終わる必要がある。名前の途中で集合が尽き、どちらの終端もなければ、その部分名は捨てる。既知に見えるラベルが並んでいても、欠けた末尾を補完する権限にはならない。

復号されたリストを使う段階で、リゾルバー方針が名前を作る。RFC 3397 は RFC 1535 と RFC 1536 の安全上の助言を参照した。検索リストはホスト名から推測せず明示する。点を含む入力はまず完全名として試し、失敗後にローカル接尾辞を付ける。点のない入力には直ちに検索接尾辞を適用できる。

ここが転送の入口だった。利用者が myhost を myhost.bigco.com の略だと思っていても、悪意ある DHCP サーバーが roguedomain.com を設定すれば、端末は myhost.roguedomain.com を問い合わせる。DNS 応答を偽造する必要はない。真偽を問う対象そのものが先に差し替わっている。

RFC 3397 は、DNSSEC がこの攻撃を防がないと明記した。攻撃側ドメインの運用者は、自分のレコードを公開して正しい鍵で署名できる。DNSSEC は、そのデータが問い合わせ名に対して真正であり改変されていないことを示す。しかし、その問い合わせ名が利用者や管理者の意図だったとは示さない。

これは暗号の失敗ではなく、証明範囲の境界である。ローカル設定が優先順位を決め、DHCP がリストを提示し、クライアントが認証・受理・復号を行う。リゾルバーが候補を構成し、DNS が応答し、DNSSEC がそれを検証し、最後にアプリケーションが接続する。後段の証拠は前段の選択を遡って承認できない。

接尾辞の操作は、不正な DNS サーバーを単に通知するより有効になり得ると文書は考えた。攻撃者は自分のドメインの通常の権威サーバーと正当なデータを使える。異常なリゾルバーも偽署名も不要であり、見える応答経路は正常なままである。分岐はその前に起きた。

対策も前段へ向けられた。RFC 1536 の検索動作を実装し、手動設定された DNS パラメーターを DHCP で上書きせず、必要ならオプション119を受理する前に DHCP 認証を要求する。ただし認証された DHCP メッセージも、許可された主体から来たことを示すだけで、個々の利用者の意図までは証明しない。

運用証拠には段階ごとの受領証が要る。元の短い入力、手動リストと取得リスト、その順序と由来、サーバー識別、認証判断を残す。次に119の生断片、RFC 3396 の集合、ポインター先、破棄した部分名、候補順を保存する。そのうえで実送信した DNS 問い、検証結果、返却アドレス、アプリケーション接続を結び付ける。

パケットにオプションが見えるだけでは受理を証明しない。リストを正しく復号できても利用を証明しない。DNS 問い合わせだけでは元の入力を復元できないことがある。署名の成功から接尾辞の由来は分からない。すべてを「名前解決成功」に畳むと、行き先を変えた権限移動が消えてしまう。

IANA の BOOTP/DHCP パラメーター表は119の協調割当を示すが、普及や実装の正しさは示さない。RFC Editor の現在の検索では RFC 3397 に一致する正誤表はない。これもパーサー、手動優先、実行時の候補順に対する認証ではない。

Lu Heng の最小初期仕様という原則から見ると、文書の節度が分かる。DNS 限定の範囲、符号化、集合内のポインター空間、正しい終端という、独立実装が共有すべき最小境界だけを定めた。実行コード優先の原則は、その先の試験を求める。ポインターを断片境界にまたがせ、集合から実際の DNS パケットと接続先まで観察するのである。

RFC 3397 が残した教訓は、署名付き応答を疑えということではない。署名が何を証明するかを狭く正確に扱えということである。署名は、すでに選ばれた名前に対するデータを認証する。その名前が正しかったかを知るには、誰が問いを組み立てたかという別の証拠が必要になる。

出典