要約

  • RFC 9532 の next-hop-aliases は、プロキシが次ホップの解決で受け取った別名と正規名を Proxy-Status に載せる。
  • 情報は不完全、空、または欠落し得る。DNSSEC 情報を含まず、信頼範囲はプロキシと利用したリゾルバまでである。
  • 判断記録では、報告者、DNS 応答、検証、端点認証、ローカルポリシー、実行結果を別々に結び付ける必要がある。

文字列には三つの名前が並んでいた。画面上では一本のきれいな経路に見える。しかし、その表示が正しい名前を再現しているかを確かめるには、少なくとも二つの文法と一つの観測経路をさかのぼらなければならない。

RFC 9532 が定義する next-hop-aliases は、HTTP の Proxy-Status パラメータである。プロキシが次ホップを DNS で解決した際に受け取った CNAME の別名と正規名を、クライアントへ伝えられる。転送プロキシに解決を委ねたクライアントは、その途中の名前を自分では見ていない。別名の列を返すことで、トラッカーや悪意ある宛先が無害に見える名前の背後へ隠れる CNAME cloaking を調べやすくなる。

ここで戻るのは、プロキシが見たという情報である。DNS 権威の署名済み履歴ではない。

HTTP の文字列と DNS の名前を混同しない

外側は RFC 8941 の Structured Fields 文字列である。その内側に、RFC 9532 独自のカンマ区切りリストが入る。元の要求名を含めてもよく、受信順に別名から最終の正規名まで並べることが望ましい。

ところが DNS 名自体にもカンマを含められる。その場合は percent-encoding が必要になる。ラベル内のピリオドは先にバックスラッシュで escape し、そのバックスラッシュをさらに符号化する。字面のバックスラッシュには別の規則がある。

処理順を誤れば、通信は成功しても別の名前を生成できる。監査では生の HTTP フィールド、Structured Fields の解析結果、percent-decoding、DNS ラベルの復元、最終表示を順番に残すべきだ。完成した UI だけでは、送信者と受信者のどちらが名前を変えたのか分からない。

規格どおりでも途中が抜ける

プロキシが全連鎖を取得できるとは限らない。RFC 9532 は、一般的な getaddrinfo が AI_CANONNAME で最後の正規名だけを返し、途中の別名を返さない場合があると説明する。そのため実装は、不完全な情報を載せてもよい。

正しく parse できることと、履歴が完全であることは別である。

フィールドがない場合、空文字の場合、名前が入っている場合、解析できない場合を分けなければならない。欠落は未対応、非該当、途中での削除、または単なる未送信を意味し得る。空文字は、そのプロキシがその解決で CNAME を見なかったと述べているだけだ。別のリゾルバ、時刻、cache、split DNS では違う答えになり得る。

さらに、再帰リゾルバや権威リゾルバが cloaking を隠すため CNAME を省くことも、悪意あるプロキシが報告しないことも可能である。報告がないことを「別名がない」と翻訳してはいけない。

DNSSEC の有無はこの欄から読めない

RFC 9532 は、パラメータが DNSSEC 情報を含まず、DNSSEC を使ったことも意味しないと明記する。情報は hint であり、アクセスした資源の身元を決めるために使うべきではない。信頼できる範囲は、プロキシとそのリゾルバを信頼できる範囲に限られる。

RFC 4033 と RFC 4035 が扱う DNSSEC は、DNS データの出所と完全性、信頼の連鎖、存在しないことの認証を別の材料で検証する。next-hop-aliases には署名も検証結果も入っていない。

DNSSEC が別途成功しても、TLS の鍵保持、HTTP authority、アプリケーションの主体、Cookie の送信権限、データ開示の許可までは決まらない。名前解決の証拠を、アプリケーションの権限へ持ち上げるには別の判断が必要になる。

まず証言者を特定する

RFC 9209 の Proxy-Status は、中間者が要求をどう処理したか説明するためのものだ。従って、記録は「どの名前が書かれていたか」より前に「誰が書いたか」を必要とする。

プロキシの識別と信頼関係、ソフトウェア版、応答経路上の位置を記す。利用したリゾルバ、検証設定、cache、構成 epoch を記す。DNS 質問、CNAME、最終名、アドレス、TTL、別に取得した DNSSEC 材料を保存する。そのうえで、連鎖が完全か、どの順で符号化したか、クライアントがどう解いたかを残す。

最後に接続、端点認証、ローカルポリシー、判断者、実際の動作を結ぶ。名前、応答、プロキシ報告、検証、認証、認可、結果は、それぞれ異なる現実層である。

共有するのは最小限の形式でよい

RFC 9532 は、すべてのクライアントに同じ遮断判断を命じない。共有するのは観測を伝える形式であり、Cookie、アクセス、警告、追加検査の方針はローカルに残る。これは Heng Lu の最小初期仕様と running-code の考え方に合う。IANA に名前が登録された事実ではなく、DNS 応答から proxy の encoding、client の parsing、policy の結果まで実行されたことが証拠になる。

公開資料は具体的なブラウザやプロキシの採用、普及率、cloaking の頻度、実事件の成否を示していない。RFC の例は仕組みの説明であり、実装報告ではない。

この不確実性を残したままでも、パラメータは十分に有用である。プロキシが見た別名を示す。それ以上の身元判断を、示したふりはしない。

情報源