偽応答が競争する位置

社内キャッシュDNS-Rが受注サイトorders.example.testのIPを通常と異なる値として返し、利用者が偽サイトへ誘導された。偽のA応答が入ったのか、上位委任が書き換えられたのか、正規の権威側が侵害されたのかを分ける。DNSの応答照合条件とDNSSECの検証点を読めば、キャッシュポイズニングの成立と失敗を説明できる。

読む順序は、用語→実際の構成と処理→記録の照合→異常の成立条件→変更・復旧→短答演習です。以下の組織、アドレス、時刻、識別子、ログは教材用の架空例です。観測できた事実と、追加調査が必要な推論を分けて読みます。

1. 用語をこの事案の判断に結び付ける

用語	意味とこの事案での判断の限界
DNSキャッシュポイズニング	再帰リゾルバのキャッシュへ偽のRRsetを入れ、後続利用者へ誤った応答を返させる攻撃。偽応答が到着しただけでは採用されたとは言えない。
カミンスキー攻撃	ランダムな未解決サブドメインへの問い合わせを繰り返し誘発し、応答競争で親側委任など有害な情報をキャッシュへ混入させる手法。単一Aレコードの上書きだけに限定しない。
TXID / 送信元ポート	DNS要求と応答を結ぶ16-bit Transaction IDとUDP送信元ポート。偽応答は宛先・問い合わせ名・型等も一致させる必要がある。予測可能なら成功確率が上がる。
bailiwick	問い合わせに関係する権威範囲外の追加情報をキャッシュへ採用しないための境界。名称だけで保護十分とは言えず、実装の受入れ条件を確認する。
DNSSEC	DNSデータの出所認証と完全性を検証する拡張。通信の秘匿や権威DNS自体の侵害、誤った正規設定を自動的には防がない。
DNSKEY	ゾーンの署名を検証する公開鍵を公開するRR。DNSKEY単体を外から得ただけでは信頼できず、上位DSまたは信頼アンカーとの関係を検証する。
DS	親ゾーンが子ゾーンのDNSKEYを指すダイジェストを公開するRR。親から子への信頼の連鎖をつなぐ。子ゾーンに置くものと混同しない。
RRSIG	RRsetに対する署名と有効期間、鍵識別子などを含むRR。AやDNSKEY等のRRsetごとに検証する。署名があるだけで検証成功ではない。
信頼アンカー	検証リゾルバが最初から信頼する鍵情報。一般にルートの鍵を起点にDS→DNSKEY→RRSIGを検証する。更新と時刻同期が必要。

2. 構成と判断する位置

架空のA社DNS-Rは再帰・キャッシュ機能を持ち、orders.example.testのAを問い合わせる。攻撃者は社内端末からランダムなa1.orders.example.test等を繰り返し引かせ、権威DNSからの正規応答より先に偽応答を送る。DNS-RはUDPポートとTXIDを照合し、DNSSEC検証も有効にしている想定。09:04の偽応答はTXID一致だが送信元ポート不一致で拒否され、09:05の別応答は形式一致でもRRSIG検証に失敗した。

偽応答が競争する位置

キャッシュDNSが応答を採用する前に照合と検証をする。

偽応答が先に届いても、未処理の要求、送信元・宛先ポート、TXID、QNAME/QTYPE、権威範囲などの照合を通過しなければ採用されない。DNSSECで署名付きゾーンを検証する場合は、さらに信頼の連鎖が必要。

3. 正常時の処理と管理

スタブリゾルバからDNS-Rへ要求し、DNS-Rがキャッシュヒットか、権威DNSへの問い合わせが必要かを決める。
DNS-Rは未処理要求ごとにTXIDとUDP送信元ポートを選び、応答の質問名・型・送信元等との対応を確認する。
得た委任・追加セクションのRRを権威範囲と受入れ規則で評価し、無関係なデータをキャッシュへ入れない。
署名付きゾーンなら、信頼アンカーから親DS、子DNSKEY、RRsetのRRSIGを検証し、署名期限とアルゴリズムも確認する。
検証に成功したRRsetだけをTTL内でキャッシュし、失敗をSERVFAIL等として返すかはリゾルバの実装と設定で確認する。

DNSSEC未署名ゾーンでは『署名がない=攻撃』とは限らない。親ゾーンにDSがないことを正当に証明できる場合、検証結果はInsecureとなり得る。一方、親DSがある署名付きゾーンで署名が壊れていればBogusとして拒否する。

4. 設定・記録のフィールドを読む

項目	読み方と注意点
QNAME / QTYPE	問い合わせ名とA/AAAA/NS等の型。ランダムサブドメイン大量要求はカミンスキー型の手掛かりだが、正規CDNや計測も考慮する。
TXID / port	未処理要求と応答の照合。片方が一致しても他方が違えば採用しない。実装やNATによるポート変換も確認する。
AA / authority / additional	権威応答や委任、追加A/AAAAの位置。AAビットだけで正しさを保証せず、bailiwickと署名を確認する。
TTL / cache entry	採用されたRRsetの残存期間と挿入時刻。異常応答が一件あってもキャッシュへ入ったかは別の証拠が要る。
DS digest / key tag	親側のDSが子DNSKEYを指す。ダイジェストと鍵タグだけでなくアルゴリズムと鍵実体を照合する。
DNSKEY / RRSIG	子側公開鍵とRRset署名、署名の開始・終了時刻。リゾルバの時計がずれると有効な署名でも失敗し得る。
validation status	Secure、Insecure、Bogus、Indeterminateの意味を区別。ADビットの有無だけで端末側が検証したと断定しない。

以下は架空のDNS-R診断ログ。表示語は実装に依存する説明用の形式で、実在のBIND/Unboundの出力ではない。

text

09:04 query=orders.example.test/A txid=0x41a2 port=53021
09:04 reply=198.51.100.8 txid=0x41a2 port=53022
  result=drop reason=port-mismatch
09:05 query=orders.example.test/A txid=0x6b91 port=51410
09:05 reply=198.51.100.8 txid=0x6b91 port=51410
  dnssec=bogus reason=rrsig-validation-failed cache=no
09:06 reply=192.0.2.20 dnssec=secure cache=yes ttl=300

09:04の偽応答はポート不一致、09:05は署名検証失敗でキャッシュへ入っていない。09:06の検証済み192.0.2.20が採用されたという設定例である。攻撃者が実際にキャッシュを汚染したと答えるのは誤り。端末が別DNSやブラウザ内のキャッシュを使う可能性は別に調べる。

5. 異常が成立する条件と証拠

状態・攻撃	成立条件、証拠、対策の位置
TXID予測	16-bit値だけを狙える実装では偽応答の当たりを付けやすい。送信元ポートのランダム化と厳密な照合で難度を上げる。
ポート固定化	NATや実装が送信元ポートを固定すると有効な変数が減る。リゾルバの外向き実ポートを測定する。
ランダム名の連続要求	未解決名を次々引かせると攻撃機会を増やせる。問い合わせ量、同一親ドメイン、委任情報の変更を監視する。
bailiwick逸脱	関係ない追加レコードを採用すると不正なIPやNSがキャッシュされ得る。実装の受入れ規則を確認する。
DNSSEC検証なし	権威が署名していてもDNS-Rで検証しなければ偽データを拒否できない。検証を誰が行うかを確認する。
正規権威の侵害	攻撃者が権威側や署名鍵を支配すれば正しい署名付きの悪性変更もあり得る。変更監査と鍵保護が必要。

DNSSECはDNSデータの真正性・完全性を検証する。TLSのようにDNS通信を暗号化するものではなく、フィッシングサイトそのものの安全性も保証しない。リゾルバがDNSSECを検証する設定か、端末が別経路を使っていないかが重要。

6. 調査で結論を強くする順序

判定段階	必要な証拠と結論の上限
偽応答は届いたか	パケット・ログで到着を確認。到着だけでは採用・利用は示さない。
照合を通ったか	未処理要求、TXID、外向きポート、質問名、型、送信元とbailiwickを確認。
署名を検証したか	親DS、子DNSKEY、RRsetのRRSIG、時刻、信頼アンカーを順に確認。
キャッシュへ入ったか	採用されたRRsetとTTL、挿入時刻、後続利用者への回答を確認。
誘導されたか	端末の実際のDNS経路とWeb接続先、証明書、プロキシを確認。キャッシュ汚染だけで閲覧成功を断定しない。

カミンスキー型では、未解決のランダム名を次々問い合わせさせることでキャッシュミスを作り、応答競争を繰り返す。狙いは個々のランダム名だけでなく、委任先NSや追加情報を汚染して親ドメイン以下へ影響を広げることにある。リゾルバがどの情報を権威範囲内として採用するかが鍵になる。

従来DNSのUDP応答は、少なくとも未処理要求に対応するQNAME/QTYPE、TXID、送信元・宛先を確認する。TXIDが16-bitなので、送信元ポートも予測困難にして偽応答の成功確率を下げる。NAT機器が外向きポートを固定・規則的にすると、リゾルバ内部のランダム化だけでは期待どおりの効果が出ない。

DNSSECのDSは子ゾーンではなく親ゾーンの委任点に置かれる。親の署名済みDSが子DNSKEYのダイジェストに対応し、そのDNSKEYが子の署名を検証する。DS→DNSKEY→RRSIG(A RRset)とたどる。DNSKEYを同じDNS応答から受け取っただけで信頼したら偽鍵も受け入れてしまう。

RRSIGは一つのDNS応答全体ではなくRRsetを覆う。AのRRset、DNSKEYのRRsetなど、それぞれに検証が必要。署名の有効期間を超えた場合や鍵ロールオーバーでDSとDNSKEYが不一致の場合、正常運用のドメインでもBogusとなり名前解決が失敗する。攻撃と設定障害を切り分ける。

DNSSEC検証状態のSecureは信頼アンカーから連鎖してRRsetを検証できた状態。Insecureは未署名への正当な委任を確認した状態で、偽装の証明ではない。Bogusは署名が必要なのに検証失敗、Indeterminateは信頼の起点がないなど判断不能を指す。用語を『署名あり/なし』の二値に潰さない。

検証リゾルバのADビットは応答の検証結果を伝える手掛かりだが、スタブとリゾルバ間が保護されないなら端末がそのビットだけを無条件で信じるべきではない。どの主体が実際に検証し、端末がどのDNSサーバを使用したかを確認する。

キャッシュを消す操作は誤答の拡散を止める一手だが、攻撃者が同じ条件を再現できれば再汚染される。外向きポート、TXID、bailiwick、DNSSEC検証、権威側変更、別DNS経路を直し、再問い合わせが安全な応答を返すことを確認する。

7. 変更・障害・例外運用

運用場面	崩れやすい条件と確認
DNSSEC鍵更新	親DSと子DNSKEYの切替順序・TTL・署名有効期間を計画。失敗時はBogusで正規名も解決できなくなる。
NAT変更	DNS-Rの外向き送信元ポートが固定化されていないか検証する。内部ポートの設定だけを見ない。
署名なしゾーン	親にDSがない場合のInsecureと、署名付きゾーンのBogusを区別して監視・説明する。
キャッシュ削除	汚染範囲とTTLを記録し、削除後に攻撃条件を閉じてから再問い合わせ・端末接続を試す。
別DNS利用	ブラウザDoHや外部DNSを使う端末はDNS-Rの検証・監視を通らない場合がある。実経路を確認する。

DNSSECの鍵ロールオーバーは安全性と可用性の両面に影響する。緊急時に検証を全停止して解決だけを戻すと偽答を受け入れるため、原因と暫定範囲、期限、代替確認を記録する。

8. 封じ込めと復旧条件

偽DNS応答の判断

1. 応答到着：対応要求との対応を確認／確認する証跡 TXIDとポート
2. 署名検証：対応信頼連鎖をたどる／確認する証跡 DS・鍵・RRSIG
3. 採用確認：対応 RRsetとTTLを読む／確認する証跡キャッシュ記録
4. 端末確認：対応実接続先を調べる／確認する証跡 DNSとWeb記録

到着、採用、利用を別々に確かめる。

偽応答の到着を侵害と誤記しない。09:04はポート、09:05はDNSSECで落ちている。別経路の端末や、権威側の正規署名付き変更が原因の場合は対応が変わる。

DNS-Rのパケット・監査・キャッシュ状態を保全し、対象RRsetとTTL、利用端末を列挙する。
TXID、外向きポート、QNAME/QTYPE、bailiwick、DNSSEC検証のどこで偽応答が採用されたかを確認する。
必要なキャッシュ削除と設定修正、NATのポート動作、信頼アンカー・親DS・子DNSKEYの整合を確認する。
権威DNSのゾーン変更・署名鍵の侵害有無を調べ、端末の別DNS経路も確認する。
再問い合わせで正しい検証済みRRsetが返り、端末のWeb接続先と証明書が正しいことを確認する。

キャッシュのAレコードを修正しても、不正なNS委任が残れば再び誤答が出る。Aだけでなく親委任、追加情報、鍵と署名の状態を検証し、TTL経過後にも再確認する。

9. 科目B（午後）の解答手順

問題文に偽応答があるときは、まずTXID・ポート等が未処理要求に合うか、次にDNSSECの連鎖が通るか、最後にキャッシュと端末の接続先を確認する。DSは親、DNSKEYとRRSIGは子側の検証に使う、と配置まで書く。

偽応答の到着とキャッシュ採用を分ける。
TXID、送信元ポート、QNAME/QTYPE、bailiwickを読む。
親DS→子DNSKEY→RRsetのRRSIGをたどる。
Secure、Insecure、Bogusの意味を区別する。

10. 短答演習

演習1：TXID一致

条件：偽応答のTXIDは同じ、ポートが違う。

質問：採用されるか。

解答：拒否される。未処理要求のポートとも一致が必要。

誤答の理由：TXIDだけで照合が完了すると考えている。

演習2：DSの配置

条件：example.testのDSを探す。

質問：どこにあるか。

解答：親の委任点に置かれる。

誤答の理由：子ゾーンのDNSKEYと混同している。

演習3：DNSKEY取得

条件：子からDNSKEYを受け取った。

質問：そのまま信頼できるか。

解答：できない。親DSと信頼アンカーから連鎖を検証する。

誤答の理由：偽鍵を排除する根拠がない。

演習4：Bogus

条件：親DSがありRRSIG検証失敗。

質問：どの状態か。

解答：Bogusであり、通常は回答を受理しない。

誤答の理由：未署名のInsecureと混同している。

演習5：カミンスキー型

条件：ランダムな未解決名が大量発生。

質問：何を狙うか。

解答：応答競争を繰り返し、委任等の有害情報をキャッシュへ混入させ得る。

誤答の理由：一つのAレコードへの単発試行だけと考えている。

演習6：ADビット

条件：DNS-Rの応答にADがある。

質問：端末自身が検証したか。

解答：断定できない。どのリゾルバが検証し、経路が保護されたか確認する。

誤答の理由：ビットの表示を端末での検証証明と扱っている。

11. 一次資料

RFC 5452：偽DNS応答への耐性

RFC 4033：DNSSECの概念と信頼連鎖

RFC 4034：DS・DNSKEY・RRSIG

RFC 4035：DNSSEC検証処理

ICANN：DNSSECの信頼アンカー

DNSキャッシュポイズニング・カミンスキー攻撃とDNSSEC