インターネットを利用する際、私たちが意識せずに恩恵を受けている重要なインフラがDNS（Domain Name System）です。Webサイトの閲覧、メールの送受信、アプリケーションの通信など、あらゆるネットワーク活動の裏側でDNSは稼働しています。その重要性ゆえに、DNSはサイバー攻撃の標的になりやすく、攻撃手法も年々高度化しています。
情報処理安全確保支援士試験においては、DNSの仕組みを深く理解していることが必須です。単に「ドメインをIPアドレスに変換する」という表面的な理解ではなく、どのようなプロトコルで通信が行われ、どこに脆弱性が潜んでいるのか、そして攻撃者はその隙をどう突いてくるのかを論理的に把握する必要があります。
本記事では、DNSの基本的な動作原理から、代表的な脅威であるDNSキャッシュポイズニング、そしてその進化系であるカミンスキー攻撃まで、技術的な背景を含めて詳細に解説します。
DNSの基本構造と名前解決のメカニズム
DNSは、人間が理解しやすい「ドメイン名（例: example.com）」と、コンピュータが通信に使用する「IPアドレス（例: 192.0.2.1）」を紐付けるシステムです。この変換プロセスを「名前解決」と呼びます。インターネットの初期には、すべてのホスト名とIPアドレスの対応表（hostsファイル）を各端末で管理していましたが、接続端末の爆発的な増加に伴い、分散データベースシステムであるDNSへと移行しました。
階層化された分散データベース
DNSの最大の特徴は、その階層構造にあります。世界中のすべてのドメイン情報を一台のサーバーで管理することは不可能なため、情報はツリー状の階層構造で管理されています。
最上位にはルート（Root）が位置し、ドット（.）で表されます。世界中に分散配置されたルートサーバーが管理しています。その下にトップレベルドメイン（TLD）として .com、.jp、.net など国や組織の種類を表す層があります。さらにその下に第2レベルドメイン（2LD）として、example.co.jp の場合の .co 部分や example.com の場合の example 部分が位置します。example.co.jp における example 部分は第3レベルドメイン（3LD）と呼ばれます。
この階層構造により、ドメイン名の管理権限を委譲（Delegation）することが可能となり、インターネットの拡張性を支えています。各階層で管理責任を分散することで、世界規模のシステムとして機能しているのです。
DNSサーバーの役割分担
名前解決には、大きく分けて2種類のDNSサーバーが関与します。それぞれ異なる役割を担い、協調して動作することで効率的な名前解決を実現しています。
DNSキャッシュサーバー（フルサービスリゾルバ）は、クライアント（PCやスマホ）からの問い合わせを受け、名前解決を代行するサーバーです。社内ネットワークやISP（インターネットサービスプロバイダ）に設置されています。一度取得した情報は一定期間保存（キャッシュ）し、再利用することでトラフィックを削減し、応答速度を向上させます。
権威DNSサーバー（コンテンツサーバー）は、自身の管理するドメインの情報を持ち、問い合わせに対して最終的な回答（IPアドレスなど）を返すサーバーです。階層ごとに存在し、それぞれのドメインゾーンに対して正式な情報を提供する権限を持っています。
再帰的問い合わせと反復問い合わせ
名前解決の流れは、2つの問い合わせ方式の組み合わせで行われます。これらの方式を理解することは、DNS攻撃のメカニズムを把握する上で非常に重要です。
再帰的問い合わせ（Recursive Query）は、クライアントからキャッシュサーバーへの「このドメインのIPを教えて（最後まで責任を持って調べて）」という依頼です。クライアントは最終的な回答だけを受け取ればよく、途中のプロセスを意識する必要はありません。
反復問い合わせ（Iterative Query）は、キャッシュサーバーが、ルートサーバー、TLDサーバー、権威サーバーへと順次「このドメインの管理者を教えて」と尋ねて回るプロセスです。各サーバーは「次に問い合わせるべきサーバー」の情報を返します。
具体的な例として、クライアントが www.example.co.jp にアクセスする場合の流れを見てみましょう。まず、クライアントはキャッシュサーバーに問い合わせます。キャッシュサーバーはルートサーバーに .jp の管理サーバーを尋ね、ルートサーバーは .jp のDNSサーバーのIPを返します。次に、キャッシュサーバーは .jp のDNSサーバーに .co.jp の管理サーバーを尋ねます。これを繰り返し、最終的に example.co.jp の権威サーバーからWebサーバーのIPアドレスを取得します。キャッシュサーバーは結果をクライアントに返し、同時にその情報をキャッシュします。
DNS通信のプロトコルと脆弱性
DNSは、その設計思想において「信頼」を前提とし、パフォーマンスを重視して作られています。この設計方針が、現代におけるセキュリティ上の課題を生む要因となっています。
UDPの使用とステートレス性
DNSの標準的なクエリ（問い合わせ）と応答には、トランスポート層プロトコルとしてUDP（User Datagram Protocol）の53番ポートが使用されます。UDPはTCPと異なり、接続の確立（ハンドシェイク）を行わず、パケットを一方的に送りつけるプロトコルです。これにより通信のオーバーヘッドが小さく高速な名前解決が可能ですが、同時に「送信元の偽装（IPスプーフィング）」が容易であるという弱点も抱えています。
TCPでは、3ウェイハンドシェイクによって通信相手の実在性をある程度確認できますが、UDPにはそのような仕組みがありません。攻撃者は自由に送信元IPアドレスを詐称したパケットを送信できるため、正規の応答になりすますことが可能になります。
なお、ゾーン転送や応答サイズが512バイト（EDNS0非対応の場合）を超える場合にはTCPが使用されることもありますが、通常の名前解決はUDPが基本です。
同一性の確認手段の限界
キャッシュサーバーが受け取った応答が「本当に自分が送った問い合わせに対する正当な応答か」を判断するための材料は、極めて限られています。主に以下の情報のみです。
- 送信元IPアドレス
- 送信元ポート番号
- 送信先ポート番号（53番）
- トランザクションID（Query ID）
トランザクションIDは、問い合わせパケットに含まれる16ビット（0～65535）の識別子です。キャッシュサーバーは問い合わせ時にランダムなIDを付与し、戻ってきた応答に含まれるIDが一致することを確認します。しかし、16ビットという情報量は約65,000通りしかなく、現代の計算機の性能からすれば決して大きな数ではありません。
攻撃者が「偽のIPアドレス」と「偽の応答データ」を作成し、正規の権威サーバーからの応答よりも早くキャッシュサーバーに到達させることができれば、キャッシュサーバーはその偽情報を正しい情報として受け入れてしまいます。これがDNSに対する攻撃の基本原理です。
認証や暗号化の仕組みが存在しないため、パケットの内容が改ざんされていないことを検証する手段もありません。この「性善説」に基づいた設計が、現代のセキュリティ要件とのギャップを生んでいます。
DNSキャッシュポイズニングの脅威
DNSキャッシュポイズニングは、キャッシュサーバーに偽の情報を記憶（キャッシュ）させ、利用者を有害なサイトへ誘導する攻撃です。一度汚染されたキャッシュは、TTL（Time To Live：生存時間）が切れるまで残り続けるため、その間、多くのユーザーが影響を受けます。
攻撃のメカニズム
攻撃者は以下の手順で攻撃を仕掛けます。
まず、攻撃者は標的となるキャッシュサーバーに対して、攻撃対象ドメイン（例：www.bank.example.com）の解決を依頼します。キャッシュサーバーは、その情報をキャッシュしていない場合、正規の権威サーバーへ反復問い合わせを行います。
この時、正規のサーバーが応答を返すまでの「わずかな隙」を狙い、攻撃者は大量の偽の応答パケットをキャッシュサーバーに送りつけます。偽のパケットには、正規のサーバーになりすました送信元IPと、攻撃者が推測したトランザクションIDが含まれています。
もし、正規のパケットより先に偽のパケットが到着し、かつトランザクションIDが一致した場合、キャッシュサーバーはそれを正当な応答として取り込みます。以降、そのキャッシュサーバーを利用する全ユーザーは、www.bank.example.com にアクセスすると攻撃者が用意した偽サイト（フィッシングサイト等）へ誘導されます。
この攻撃の恐ろしさは、一度成功すれば、そのキャッシュサーバーを利用する数千、数万のユーザーが一斉に被害を受ける可能性がある点です。個別のPCを狙うマルウェアとは異なり、インフラレベルでの攻撃となるため、被害規模が桁違いに大きくなります。
従来型攻撃の限界とカミンスキー攻撃の登場
従来のキャッシュポイズニング攻撃は、成功率がそれほど高くありませんでした。なぜなら、攻撃が失敗した場合（正規の応答が先に届いた場合）、正しい情報がキャッシュされてしまうからです。正しい情報には長いTTL（多くの場合、数時間から数日）が設定されていることが多く、そのTTLが切れるまで次の攻撃チャンスが巡ってきません。
つまり、攻撃者は一度の問い合わせに対して限られた試行回数しかチャンスがなく、失敗すれば長時間待たされるというジレンマを抱えていました。16ビットのIDを総当たりで当てる確率は約1/65,000であり、このリスクとリターンのバランスは攻撃者にとって必ずしも有利ではありませんでした。
この常識を覆したのが、2008年にセキュリティ研究者ダン・カミンスキー氏によって発表された「カミンスキー攻撃（Kaminsky Attack）」です。この攻撃手法の発見は、DNS業界に大きな衝撃を与え、世界中のDNSサーバーに対する緊急パッチの適用が呼びかけられる事態となりました。
カミンスキー攻撃の手法
カミンスキー攻撃の革新的な点は、「存在しないサブドメイン」を問い合わせ続けることにあります。この巧妙な手法により、TTLの制約を完全に回避できるようになりました。
具体的な攻撃手順を見てみましょう。攻撃者は 1.bank.example.com、2.bank.example.com、3.bank.example.com といった、実在しないランダムなサブドメインの問い合わせを連続して行います。これらのサブドメインはキャッシュに存在しないため、キャッシュサーバーは毎回必ず権威サーバーへ問い合わせを行います。
ここで重要なのは、攻撃者がこれらの問い合わせに対する偽の応答の中に、「bank.example.com ゾーン全体の権威サーバーは攻撃者のサーバーである」という偽の情報を忍ばせることです。DNS応答には、質問に対する直接の回答だけでなく、関連する追加情報（グルーレコードや追加セクション）を含めることができます。攻撃者はこの仕様を悪用します。
もし攻撃が失敗しても、問い合わせたサブドメイン（1.bank.example.com）がキャッシュされるだけで、ターゲットドメイン全体の権限情報はキャッシュされません。したがって、攻撃者はTTL待ちをすることなく、次々と異なるサブドメインで攻撃を試行できます。成功するまで無限に試行を続けられるのです。
この手法により、DNSキャッシュポイズニングの成功率は劇的に向上し、現実的な脅威として認識されるようになりました。攻撃者は時間的制約から解放され、計算リソースさえあれば高確率で攻撃を成功させられるようになったのです。
その他のDNS関連脅威
キャッシュポイズニング以外にも、DNSの特性を悪用した攻撃が複数存在します。これらを理解することで、DNSセキュリティの全体像を把握できます。
DNSリフレクション攻撃（DNS Amp）
DNSリフレクション攻撃は、DDoS攻撃の一種であり、DNSの「増幅効果」を悪用します。攻撃者は、送信元IPアドレスを「攻撃対象のIP」に偽装し、オープンリゾルバ（外部からの問い合わせを無制限に受け付ける不適切な設定のDNSサーバー）に対して問い合わせを行います。
この際、攻撃者は「問い合わせは小さく、応答は大きい」リクエストを送ります。例えば、ANY レコードの要求や、DNSSEC署名付きのレコード要求などです。わずか数十バイトの問い合わせに対して、数千バイトの応答が返されることもあります。
オープンリゾルバは、偽装された送信元（つまり攻撃対象）に対して、増幅された大きなサイズの応答パケットを一斉に送りつけます。攻撃者が世界中の多数のオープンリゾルバを利用すれば、少ないトラフィックで大量の攻撃トラフィックを生成でき、攻撃対象の回線をパンクさせます。
この攻撃の増幅率は数十倍から数百倍に達することもあり、DDoS攻撃の手法として広く使われています。防御策として、DNSサーバーをオープンリゾルバとして運用しないことが重要です。
DNSトンネリング
DNSトンネリングは、DNSプロトコルをデータの運搬手段として悪用する手法です。多くの企業ネットワークでは、外部へのWebアクセスなどが厳しく制限されていますが、DNSクエリは業務上必須のため、ほぼ無条件で許可されているケースが多くあります。
攻撃者は、盗み出したいデータをエンコードしてドメイン名の一部（例：c2VjcmV0LWRhdGE.attacker.com）に埋め込み、外部の攻撃者が管理するDNSサーバーへ問い合わせを行います。攻撃者のDNSサーバーは、問い合わせ内容からデータを抽出します。逆に、応答のTXTレコードなどに命令を埋め込むことで、C&Cサーバーとの通信チャネルとして利用することも可能です。
この手法により、ファイアウォールやプロキシを回避して情報の持ち出しやマルウェアの遠隔操作を行うことができます。近年のAPT攻撃でも使用されており、通常のネットワーク監視では検出が困難です。対策としては、DNSクエリのパターン分析や、信頼できるDNSサーバー以外への通信を制限することが有効です。
キャッシュポイズニングへの対策
DNSの脅威に対抗するために、現在では複数の対策技術が導入されています。これらの対策を組み合わせることで、攻撃成功の確率を大幅に低減できます。
ソースポートランダマイゼーション
最も基本的かつ効果的な対策の一つが、ソースポートランダマイゼーションです。この技術は、カミンスキー攻撃の発見直後に広く導入されました。
従来、DNSの問い合わせに使用する送信元ポート番号は固定や予測可能なものが多く、攻撃者はトランザクションID（16ビット＝約65,000通り）を一致させるだけで攻撃が可能でした。ソースポートランダマイゼーションでは、送信元ポート番号もランダムに変化させます。
これにより、攻撃者は「トランザクションID」と「ポート番号」の両方を一致させる必要が生じます。ポート番号として利用可能な範囲は約60,000通りあるため、組み合わせは約40億通りとなり、攻撃成功の確率を劇的に下げることができます。
ただし、これはあくまで確率的な防御であり、攻撃を不可能にするものではありません。計算能力が向上すれば、理論上は突破可能です。しかし、実用上は十分な防御効果を発揮します。
オープンリゾルバの廃止
自組織の管理下にあるネットワーク以外からの再帰的な問い合わせを拒否するように設定します。DNSサーバーの設定で、問い合わせを受け付けるIPアドレス範囲を限定することで実現できます。
これにより、DNSリフレクション攻撃の踏み台として悪用されることを防ぎます。また、第三者によるキャッシュポイズニング攻撃のきっかけを作らせないという効果もあります。公開する必要のないDNSサーバーは、必ず内部ネットワークからのアクセスのみに制限すべきです。
DNSSEC（DNS Security Extensions）
上記の対策はあくまで「偽装を難しくする」ものであり、根本的な解決ではありません。DNSSECは、電子署名の技術を用いて「応答が正当な権威サーバーから送られたものであること」と「改ざんされていないこと」を暗号学的に保証する仕組みです。
DNSSECでは、各DNSレコードにデジタル署名が付与されます。キャッシュサーバーはこの署名を検証することで、応答の正当性を確認できます。攻撃者が偽の応答を送っても、正しい秘密鍵がなければ有効な署名を作成できないため、キャッシュサーバーは偽装を検出し拒否します。
DNSSECは、確率的な防御ではなく、暗号学的に保証された防御を提供します。ただし、導入には複雑な鍵管理が必要であり、すべてのドメインで普及しているわけではありません。DNSSECの詳細については、次回の記事で解説します。
0x20ビットエンコーディング
問い合わせるドメイン名の大文字・小文字をランダムに混ぜる（例：EXaMpLe.CoM）手法です。DNSは本来大文字小文字を区別しませんが、RFC 4343により、応答パケットには質問時の文字列がそのままコピーされる仕様になっています。
キャッシュサーバーは、問い合わせ時に使用した大文字小文字のパターンを記憶しておき、応答でもそれが保持されているかを確認します。もしすべて小文字で戻ってきたら偽物と判断するなど、照合材料を増やします。
ドメイン名の長さに応じて数ビットから数十ビットの追加エントロピーが得られるため、ソースポートランダマイゼーションと併用することで、さらに攻撃成功確率を下げることができます。ただし、一部の古いDNSサーバーでは正しく動作しない場合があります。
最新ソフトウェアの適用とモニタリング
すべての対策技術も、適切に実装されていなければ意味がありません。DNSサーバーソフトウェアは常に最新版にアップデートし、セキュリティパッチを適用することが重要です。
また、DNSクエリのログを監視し、異常なパターン（大量の存在しないサブドメインへの問い合わせなど）を検出する仕組みを導入することで、攻撃の兆候を早期に発見できます。SIEM（Security Information and Event Management）システムと連携させることで、より効果的な防御が可能になります。
【理解度チェック】DNSの仕組みとセキュリティ対策 演習問題（全10問）
リード文 DNSはインターネットの根幹を支える重要インフラである一方、UDPの特性や認証の仕組みの欠如など、プロトコルレベルでの脆弱性を抱えています。 本記事で解説した「DNSキャッシュポイズニング」や「カミンスキー攻撃」の仕組み、そして「DNSSEC」などの防御策について、正しく理解できているかを確認してみましょう。 情報処理安全確保支援士試験の頻出ポイントを中心に、実践的な4択問題を作成しました。解説もあわせて確認し、知識の定着に役立ててください。
まとめ
DNSはインターネットの根幹を支える技術でありながら、その歴史的経緯からセキュリティ上の課題を抱えています。攻撃者は、UDPのステートレス性や認証の欠如といったプロトコル自体の仕様を巧みに突いてきます。
特にキャッシュポイズニングは、ユーザーを不正なサイトへ誘導し、フィッシング詐欺やマルウェア感染の入り口となる危険な攻撃です。カミンスキー攻撃の登場により、この脅威は理論上の可能性から現実的なリスクへと変貌しました。
これらの脅威を防ぐためには、DNSサーバーの適切な運用（オープンリゾルバ対策、最新ソフトウェアの適用）に加え、ソースポートランダマイゼーションのような防御策の実装が不可欠です。しかし、攻撃者の計算能力が向上すれば、確率的な防御策はいずれ突破される可能性があります。
そこで登場するのが、信頼の連鎖（Chain of Trust）によって情報の正当性を保証するDNSSECです。DNSSECは、暗号学的な手法により、DNS応答の真正性と完全性を保証します。これにより、キャッシュポイズニング攻撃を根本的に防ぐことが可能になります