要約
- DNS Cookieは、オフパスの増幅、偽造、キャッシュ汚染攻撃を難しくするための軽量なトランザクション状態である。
- 有効なServer Cookieがサーバーに与える保証は限定的で、観測した送信元アドレスから、以前の交換で見たClient Cookieを伴う問い合わせが来たことを弱く示す。
- オンパス観測者には耐えず、リゾルバーやNATの背後にいる利用者、契約者、端末所有者、アプリケーション主体を示さない。
- 運用では、Cookie検証、ネットワーク観測、リゾルバー識別、認可判断を分けたDNS問い合わせ検証記録が必要になる。
実在の事業者を想定しない仮説的な不正利用対策を考える。家庭、企業、アクセス網からのDNSトラフィックが共有再帰リゾルバーを通る。リゾルバーはエニーキャストサービスからServer Cookieを受け取り、後に同じ公開アドレスから有効な値を提示する。下流の制御系がそれを「同じ顧客が二度問い合わせた証拠」と記録する。しかしプロトコルが示すのは、二度目の問い合わせがClient Cookie、観測したアドレス、サーバーの秘密、時間窓に照らして検証できる状態を運んだ、という狭い事実である。
RFC 7873 はDNS Cookieを軽量なDNSトランザクションセキュリティ機構として定義する。対象は、やり取りを観測できないオフパス攻撃者によるDoS増幅、応答偽造、キャッシュ汚染であり、保護は限定的である。「交換を観測できない」という条件こそ保証の境界だ。
最初の問い合わせには8バイトのClient Cookieが入る。サーバーの応答後、後続問い合わせはClient Cookieと受け取ったServer Cookieを併せて送れる。サーバーは、自ら発行した状態を再現できないトラフィックを拒否または制限できる。段階的導入が可能で、NATやエニーキャストにも対応し、全クライアントに事前合意の資格情報を配る必要がない。
この利点が、RFCで「弱い認証」と呼ばれ、クライアントID基盤とされない理由でもある。平文DNSを見られる経路上のルーター、ブリッジ、共有リンク参加者などはCookieも観測できる。有効期間中は、その値を再利用し得る。Cookieはオフパス偽造者の負担を増やすが、観測可能なベアラー値を人や組織の身元証明には変えない。
RFC 9018 は相互運用可能なServer Cookie構成を定める。バージョン1では、Client Cookie、バージョン、予約フィールド、タイムスタンプ、クライアントの送信元IPアドレスをServer Secretの下で計算する。IPアドレスはCookie値に含まれないが計算入力であり、サーバーは同じ秘密で検証する。
この構成が答えるのは、あるClient Cookieと観測アドレス向けに以前生成したCookieと問い合わせが整合し、秘密と時間窓が有効か、という問いである。アドレスを誰が利用しているかは答えない。多数の人が一つの再帰リゾルバーを共有し、複数端末が一つのNATアドレスに隠れる。プロセスは再起動し、Client Cookieを更新し、別アドレスへ移ることもある。反対に、同じ公開アドレスの背後で人と権限が入れ替わることもある。
時間も証拠の一部だ。RFC 9018はタイムスタンプを定義済み期間内で検証するよう求め、過去約1時間と未来5分の許容を推奨する。受信Cookieが30分を超えれば新しい値を生成することも勧める。これは再利用を制限する窓であり、契約者アカウントの現行認可期間ではない。
エニーキャストでは別の区別が必要になる。各メンバーは互換構成を使い、互いの出力を検証する秘密を持たなければならない。RFC 9018は三段階のロールオーバーを示す。新しい秘密を全体に配りつつ旧秘密で生成し、次に新秘密で生成しながら両方を検証し、クライアント更新後に旧秘密を削除する。他メンバーがCookieを受理した事実はフリートの検証状態を示すだけで、同じ物理サーバー、同じリゾルバーの実行インスタンス、同じ利用者の再訪を証明しない。
プライバシー規則も境界を明確にする。送信元アドレスが変われば新しいClient Cookieが必要で、NAT配下のクライアントは公開アドレスの変化を検知できない場合がある。継続性はネットワーク文脈と実装状態に意図的に結び付く。永続顧客IDとして扱えば、機構の移動性とプライバシーの前提に反する。
より強い比較対象は RFC 8945 のTSIGである。TSIGは、設定済みの共有秘密を持つDNSエンティティ間でメッセージ認証コードを用い、トランザクションを認証する。動的更新や応答が鍵を持つ承認済み相手から来たことを示せるが、鍵配布、保護、明示的な信頼関係が必要になる。DNS Cookieはその負担を意図的に避ける。
TSIGにも限界があり、共有秘密を持つ当事者間の転送を認証するのであって、すべてのDNSデータの内容が正しいことや、そのデータが最初にどこで作られたかを保証するものではない。両方式が鍵付き計算を使うからといって、DNS CookieがTSIGの強い当事者認証を継承するわけではない。一方は広範な軽量防御、もう一方は事前の信頼関係に基づくトランザクション認証である。
運用上の誤りは、四つの観測を一つのID表示に圧縮することだ。Server Cookieが有効で、送信元アドレスが計算と一致しても、経路は観測され得る。リゾルバーは異なる権限の多くの利用者を代表し得る。レート制御がCookieを不正利用シグナルとして使うことと、顧客認証を宣言することは別である。
DNS問い合わせ検証記録には、Client Cookie、Server Cookieのバージョンとタイムスタンプ、検証結果、観測した送信元アドレス、応答したエニーキャストメンバー、Server Secretの世代、転送方式とオンパス露出、既知ならリゾルバーの実行インスタンス、別途認証した利用者またはサービス、認可方針、行為時刻を残す。秘密そのものは決して記録しない。
こうすれば機構の価値を保てる。有効Cookieはレート制限を補助し、反射機会を減らし、高価な制御の前に明白な偽造を選別できる。秘密更新やエニーキャスト整合性の不具合も示せる。価値は証拠を読みやすくすることにあり、脅威モデルを越えて格上げすることにはない。
出典
RFC 7873 — Domain Name System (DNS) Cookies; RFC 9018 — Interoperable DNS Server Cookies; RFC 8945 — Secret Key Transaction Authentication for DNS.
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

