DNSキャッシュポイズニングとDNSSEC（DNS cache poisoning / DNSSEC）
DNSのキャッシュに偽の対応を覚えさせ、別のサーバへ誘導する攻撃。DNSSECは答えに署名を付けて防ぐ。
もう少し詳しい説明
DNS（Domain Name System。example.com のような名前から、機器の番号を調べる仕組み）は、名前とIPアドレス（機器1台1台に割り当てられる番号）の対応を答えるだけの仕組みです。ところがその答えが偽物だったら、利用者は正しいアドレスを入力したまま、別の場所へ連れていかれます。
このページでは、その攻撃（DNSキャッシュポイズニング）と、答えが本物かを確かめる仕組み（DNSSEC）を順に見ます。
DNSキャッシュポイズニング
DNSキャッシュポイズニングは、キャッシュDNSサーバ（利用者の代わりに名前を調べ、返ってきた答えをしばらく覚えておくサーバ）に偽の対応を覚えさせ、利用者を別のサーバへ誘導する攻撃です。DNSキャッシュ汚染とも呼ばれます。
先に、2種類のDNSサーバ
DNSサーバには、役割の違う2種類があります。この2つを分けておかないと、攻撃の形がつかめません。
| 役割 | |
|---|---|
| 権威DNSサーバ | そのドメイン（インターネット上の住所にあたる名前）の正しい答えを持っているサーバ。example.com のことは、example.com の権威DNSサーバが答える |
| キャッシュDNSサーバ | 利用者の代わりに権威DNSサーバへ問い合わせ、返ってきた答えを一定時間覚えておくサーバ。会社やプロバイダ（家庭や会社をインターネットにつなぐ事業者）が用意する |
利用者のパソコンが聞きに行くのは、キャッシュDNSサーバのほうです。そこに答えが残っていればすぐ返し、無ければ権威DNSサーバまで聞きに行きます。
毎回いちばん上からたどっていては時間がかかるので、一度聞いた答えを手元に置いておくわけです。この「覚えておく」ところが、攻撃の的になります。
なぜ成立するのか
攻撃者は、本物の権威DNSサーバより先に、偽の答えをキャッシュDNSサーバへ返します。
キャッシュDNSサーバは、先に届いたほうを受け取って覚えます。
ここでは、www.example.com という名前について、本物のIPアドレスのかわりに、攻撃者のサーバのIPアドレスを覚え込まされたとしましょう。
以後、そのキャッシュDNSサーバを使っている人が www.example.com を開こうとすると、攻撃者のサーバへつながります。覚えた答えは一定時間そのまま使われるので、そのあいだ、同じことが起き続けます。
利用者の側には何も起きていません。 打ち間違えたわけでも、怪しいリンクを踏んだわけでもありません。正しいアドレスを入力しているのに、違う場所へ行きます。ここが、この攻撃のたちの悪いところです。
なぜ偽の答えが受け付けられるのか
DNSの応答は、もともと送り主を確かめる仕組みを持っていません。
受け取ったキャッシュDNSサーバは、次の条件がそろえば本物だと判断します。
| 確かめていること |
|---|
| 送信元のIPアドレスとポート番号（1台の機器の中で、どの用途あての通信かを表す番号）が、問い合わせ先と合っている |
| ID（問い合わせに付けた番号）が一致している |
このIDは16ビット（0か1が16個並ぶ長さ）、つまり65,536通りしかありません。攻撃者が当て推量で大量に送れば、当たることがあります。
対策
| 対策 | 中身 |
|---|---|
| ソースポートランダマイゼーション | 問い合わせに使うポート番号を毎回ばらばらにし、当てにくくする |
| キャッシュDNSサーバを外部に開かない（オープンリゾルバにしない） | 使わせる相手を社内や契約者に限る |
| 権威とキャッシュを分ける | 外部から自分のキャッシュに入れられる隙をなくす |
| DNSSEC | 答えそのものが本物かを確かめる |
上の3つは「当てにくくする」対策です。確率を下げているだけで、原理としては成立し得ます。
根本から解くのがDNSSECです。
オープンリゾルバ
表に出てきたオープンリゾルバを説明しておきます。
リゾルバ（resolver）は、名前を引く側という意味です。オープンリゾルバは、そのキャッシュDNSサーバが、誰からの問い合わせでも受け付けてしまう状態を指します。設定を誤ると、こうなります。
本来、会社のキャッシュDNSサーバに聞いてよいのは社員だけです。ところが外へ開いていると、世界中の誰でも問い合わせを送れます。
困ることが2つあります。
- 攻撃者が狙った名前をわざと問い合わせて、偽の答えを送り込むきっかけを作れる
- 問い合わせより応答のほうが大きいことを利用して、他人への攻撃の踏み台にされる
対策は、使わせる相手を社内や契約者に限ることです。試験では「オープンリゾルバにしない」という形で選択肢に出ます。
DNSSEC
DNSSEC（DNS Security Extensions）は、DNSの応答にデジタル署名（送り主が本人であることと、途中で書き換えられていないことを確かめる仕組み）を付ける仕組みです。
何を確かめられるのか
デジタル署名なので、確かめられることは決まっています。
| 確かめられる | 確かめられない |
|---|---|
| 正規の権威DNSサーバが出した答えであること | 内容が秘密に保たれること |
| 途中で書き換えられていないこと | ドメインの所有者が実在する組織であること |
DNSSECは暗号化（中身を、決まった手順で読めない形に変えること）ではありません。 通信の中身は、これまでどおり第三者から読めます。隠すのではなく、本物かどうかを確かめる仕組みです。
ここが試験で突かれます。「盗聴を防ぐ」と書いてあれば誤りです。
信頼の連鎖
署名を検証するには、署名した人の公開鍵が本物であるという保証が要ります。その保証を、DNSの階層をたどって作ります。
| 階層 | 何を保証するか |
|---|---|
| ルート | com の鍵が本物であることを保証する |
com | example.com の鍵が本物であることを保証する |
example.com | 自分のレコード（DNSに登録してある1件ぶんの情報）に署名する |
上が下を保証していく形です。いちばん上のルートの鍵だけは、別の方法であらかじめ配っておきます。これを信頼の連鎖（chain of trust）と呼びます。
認証局が上位から下位へ証明書を発行していく形と、考え方が同じです。
広まりにくい理由
よい仕組みですが、全面的には普及していません。
| 課題 | 中身 |
|---|---|
| 階層の全部が対応する必要 | 途中が対応していないと、連鎖が切れる |
| 応答が大きくなる | 署名を載せるぶん、パケット（通信するデータを小さく区切ったひとかたまり）が長くなる |
| 鍵の管理 | 期限があり、入れ替える作業が要る |
試験で問われるのは仕組みと目的で、普及の度合いまでは問われません。
試験ではこう出る
科目A（旧・午前）では、DNSキャッシュポイズニングの説明（偽の情報をキャッシュに覚えさせ、別のサイトへ誘導する）がそのまま出ます。
DNSSECで確認できることも頻出です。「正当なサーバからの応答であり、改ざんされていないこと」が答えで、「暗号化して盗聴を防ぐ」は誤りです。
オープンリゾルバ（誰からの問い合わせでも受け付けてしまう状態）にしないことや、ソースポートランダマイゼーションも、対策として選択肢に並びます。
応用情報では、利用者が正しいURLを入力しているのに別のサイトへ誘導されるという状況が示され、原因として何が考えられるかを答えさせる形が出ます。
関連する用語
- DNS
- 名前とIPアドレスの対応を答える仕組み。その答えを偽るのがこの攻撃
- 権威DNSサーバとキャッシュDNSサーバ
- 毒を入れられるのはキャッシュのほう
- デジタル署名
- DNSSECはこの仕組みで、答えが本物かを確かめる
- 認証局（CA）
- 上位が下位を保証する形が似ている。DNSSECは信頼の連鎖をDNSの階層で作る
ミニクイズ
DNSSECによって実現できることとして、適切なものはどれか。
正解は 4番：DNSの問合せに対する応答が、正規のサーバからのもので改ざんされていないことの確認
DNSSECは、DNSの応答にデジタル署名を付け、受け取った側が検証する仕組みです。確かめられるのは「正規の権威DNSサーバが出した答えであること」と「途中で書き換えられていないこと」の2点です。内容そのものは暗号化されないため、通信は第三者から読めます。大量アクセスの遮断は別の対策です。ドメイン名の所有者が実在する組織かどうかを証明するのは、サーバ証明書を発行する認証局の役割で、DNSSECの範囲ではありません。
この分野をまとめて解く → セキュリティのミニテスト（全47問）
最終更新：2026-10-20