要約

  • RFC 1535 は、末尾にルートを示すドットがある絶対名と、検索規則で補完され得る非ルート名を区別した。Machine.Tech.ACES.COM 上の一入力から、意図した絶対名より先に三つの候補が生成され得た。
  • 三番目の UnivHost.University.EDU.COM. は、もはや ACES.COM のローカル管理下ではない。登録済みの EDU.COM 配下にワイルドカード CNAME があれば、その応答で探索が止まり、四番目の UnivHost.University.EDU. は問い合わせられない可能性があった。
  • 修正は略称を全面禁止せず、暗黙の探索を狭め、ドットを含む入力をまず絶対名として試し、追加のローカル候補を明示設定へ移した。Informational 文書であり、導入台数、実被害、現在の脆弱性、認証済みエンドポイントを証明しない。

パケット列を管轄列として読む

RFC 1535 の例では、検索元ホストは Machine.Tech.ACES.COM、入力は末尾のドットを持たない UnivHost.University.EDU だった。BSD BIND 系の一部クライアントは次の順で名前を作り得た。

  1. UnivHost.University.EDU.Tech.ACES.COM.
  2. UnivHost.University.EDU.ACES.COM.
  3. UnivHost.University.EDU.COM.
  4. UnivHost.University.EDU.

これは単なる四パケットではない。最初の候補は Tech.ACES.COM の内部、次は ACES.COM の内部と読める。三番目は EDU.COM という別の公開枝へ移る。四番目だけが入力されたラベル列をそのままルートへ結び付ける。

文字列処理としては、検索元ホスト名の左側ラベルを一つずつ落とす規則に見える。運用上は、誰が応答できるかを順番に変更する手続きである。問い合わせの送信先が変わるだけでなく、最初に有効な応答を返した管理者が、元の入力の解釈を事実上選ぶ。

IETF Datatracker と RFC Editor の情報ページ は、文書を 1993 年 10 月の Informational RFC として記録する。テキスト版 は記述の照合に使え、Errata ページ は文書上の訂正を分離する。これらは当時の実装台数や現在の既定値を測定した資料ではない。

末尾のドットは認証ではなく探索停止命令だった

UnivHost.University.EDU. の最後のドットは DNS ルートに到達した絶対名を示す。これを付けない形は、ローカルな起点や検索リストに対して相対的に扱われ得る。

ドットは相手の身元を保証しない。証明書、ホスト鍵、応答の新鮮さ、サービスの運用主体、アプリケーション結果とは別である。ドットの役割はもっと狭い。このラベル列へ別の接尾辞を付けて解釈してはならない、と補完処理に伝える。

相対名の考え方自体は以前からあった。RFC 1034 とその STD 13 情報ページ は、相対名を origin や検索リストに対して解決する仕組みを説明し、ユーザーインターフェースの扱いが実装によって異なることにも触れていた。RFC 1035 とその情報ページ はメッセージ、資源レコード、リゾルバーの実装文脈を与える。

相対名は、管理範囲が既知なら便利である。問題は、検索元ホストのドメイン構造だけから管理範囲まで推測した点にあった。

ラベルを削っても同じ管理者の中にいるとは限らない

Tech.ACES.COM から ACES.COM、さらに COM へ移る操作は、文字列上は一貫している。しかし、委任上の所有者は連続しない。

ACES.COM の管理者は、自組織内で service.Tech.ACES.COM. や service.ACES.COM. を略称から作る方針を持てる。だからといって .COM 配下のあらゆる登録可能名に意味を与える権限はない。ACES を削った瞬間、暗黙補完はローカル方針の外へ出る。

DNS の権威サーバーは、この越境を起こしていない。EDU.COM の運用者は、自分のゾーンに来た問い合わせへ答える正当な権限を持つ。問題は、その答えを利用者の意図と競わせたリゾルバー側の候補生成にある。

したがって「権威ある応答」という表示だけでは足りない。何について権威があるかを記録しなければならない。その応答は生成候補について正しいかもしれないが、入力解釈について権威を持つわけではない。

EDU.COM は存在しなかった権限移動を可視化した

RFC 1535 は、EDU.COM が登録され、その配下のワイルドカード CNAME により *.edu.com 型の名前が一つの宛先へ向けられ得たと報告した。harvard.edu.com も具体例として挙げられた。

ここから現在の EDU.COM の設定を推測してはならない。実際に資格情報が盗まれた件数も、全 BIND 版の挙動も、この文書からは分からない。証拠が支えるのは 1993 年の報告と修正理由である。

重要なのはワイルドカードだけではない。三番目の候補に個別レコードがあっても、探索は止まり得る。危険の核は、利用者が入力していない公開枝の候補が、入力通りの絶対名より先に回答競争へ参加したことだった。

その回答が得られても、接続の成立や正しい相手の認証は別問題である。DNS 応答、TCP などのトランスポート、TLS 証明書や SSH ホスト鍵、アプリケーションの認可、利用者が見た結果を、それぞれ別の受領証として扱う必要がある。

検索順序が名前の実行仕様だった

検索リストを設定画面の文字列一覧として保存するだけでは、挙動を説明できない。少なくとも次の判断がある。

  • どの入力を補完対象にするか。
  • どの接尾辞を候補にするか。
  • 候補を何番目に試すか。
  • NXDOMAIN、CNAME、期待するレコードなどのどれで進行または停止するか。

集合が同じでも順序が違えば、先に応答する管轄が変わる。順序が同じでも停止規則が違えば、絶対名まで到達するかが変わる。キャッシュが候補を満たせば、今回のネットワークトレースに問い合わせさえ残らない。

RFC 1123 とその Host Requirements 情報ページ は略称機能を任意とし、完全名を入力する規約を要求した。また、利用者の入力から完全なドメイン名への変換は、適切な文脈で一度だけ実行すべきだとし、管理者が検索リストを無効にできることも認めた。

ルートサーバーの負荷については、別の歯止めも設けた。非ローカルな問い合わせを送る前に、ホストはネガティブキャッシュを用いるか、名前の内部に一定数以上のドットがあることを条件にするか、その両方を行わなければならない。この条件が制御するのは通信量であって、利用者の名前を解釈する権限ではない。したがって、ローカル境界や候補順序を補うが、置き換えはしない。

一度だけ、という条件は来歴を守る。アプリケーションが一度、ライブラリがもう一度補完すれば、最終名から意思決定者を特定できない。偶然正しい宛先へ着いても、なぜ着いたかは再現不能になる。

BIND 4.9.2 は暗黙の自由を狭めた

RFC 1535 の最低限の修正は、ローカルに管理される境界をパラメーター化することだった。検索元ホストのドメインを短くしていく場合も、同じ組織が管理すると確認できる深さを越えてはならない。

さらに文書は BIND 4.9.2 のより狭い挙動を説明した。暗黙に試す形を限定し、内部にドットを含む入力はまず絶対名として試す。ほかの候補が必要なら、明示的なローカル検索設定に置く。

これは「ドットが一つでもあれば常に完成名」という普遍命題ではない。複数ラベルのローカル略称に依存する組織もあった。その利用を続けることはできるが、例外は管理者が自分の範囲に対して宣言しなければならない。

明示設定も安全を自動保証しない。古い接尾辞、誤った順序、失効した管理権限は残り得る。それでも設定には出所、版、承認者、撤回手段がある。隠れた一般規則より、検査できる局所規則の方が責任を限定できる。

短く入力する利益と、誤って届く費用

略称の利益は毎日見える。入力が短く、既存の手順書やスクリプトが動く。広い検索リストを維持したチームは、解決失敗の減少を成果として受け取る。

費用は遅れて別の場所へ現れる。以前は存在しなかった公開候補が登録される、VPN が別のリストを配る、キャッシュ規則が変わる、アプリケーションが広い証明書名を受け入れる。調査費用はセキュリティ、アプリケーション、外部ゾーン、利用者へ落ちる。

DNS 成功率だけを最適化すると、意図しない候補が応答し始めた事態を改善と数える。遅延だけを最適化すると、最速の誤回答が勝つ。指標には候補の生成元と管理境界を含めなければならない。

Heng Lu の Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption は、後世の編集上の視座として役立つ。共有規則を最小にし、将来の局所判断を局所に残し、撤回可能にする。これは RFC 著者の内心を示す史料ではない。

文書、実装、応答、結果を圧縮しない

Informational RFC が存在することと、ある端末がその挙動を持つことは別である。稼働バイナリ、ライブラリ版、構成、名前空間、トレースがなければ実装事実は確定しない。

Running-Code Primacy の視点は、文書ラベルより実際の出力を確かめる。現実の層に関する論考 は、入力、補完方針、候補、DNS 応答、選択先、認証、アプリケーション結果を一つの「解決済み」にまとめない。

隣接 RFC の扱いも同じである。RFC 1536 とその情報ページ はトラフィック、再試行、再帰、キャッシュに関する実装誤りを整理した。RFC 1537 とその情報ページ は DNS データファイルの一般的な誤りを扱った。どちらも当時の診断運動を示すが、RFC 1535 の候補列そのものの証拠ではない。

必要なのは候補の台帳である

再現可能な記録は、末尾ドットを含む元の入力から始まる。呼び出したアプリケーション、検索を要求したか、リゾルバーと版、プロセスや名前空間の時期、設定の供給元、順序付きリスト、ローカル境界、方針版を残す。

各候補について、生成理由、問い合わせ時刻、トランスポート、応答種別、権威またはキャッシュ、回答、CNAME、続行・停止判断を保存する。その後に、選択された正規エンドポイント、接続、認証、認可、観測結果を別々に結ぶ。

パスワードを保存する必要はない。機微な操作では限定的な指紋、宛先の身元、認可結果で十分な場合がある。失ってはならないのは、入力が最終宛先へ変わる決定列である。

RFC 1535 の長期的な教訓は、最後のドットを覚えよ、ではない。識別子を補完するソフトウェアは、その意味を解釈できる管轄を選んでいる。その権限をローカルで証明可能な範囲に限定し、順序と停止を可視化し、最終応答を身元や成果と混同しないことが必要である。

出典