普段何気なく利用しているインターネットですが、「検索したWebサイトが、本当に正しいサイトである」という保証はどこにあるのでしょうか？実は、インターネットの住所録であるDNS（Domain Name System）は、設計当初「性善説」に基づいて作られており、「通信相手が嘘をつくかもしれない」という前提がありませんでした。
この隙を突いて、ユーザーを偽のサイトへ誘導し、IDやパスワード、クレジットカード情報を盗み取る攻撃手法が確立されています。それが「DNSキャッシュポイズニング」です。この脅威に対抗するために生まれたのが、今回解説するDNSSEC（DNS Security Extensions）です。
本記事では、DNSが抱える根本的な脆弱性から、DNSSECがどのようにして「情報の正しさ」を数学的に証明しているのか、その仕組みと運用上の課題までを、図解を交えながら徹底的に解説します。情報処理安全確保支援士試験の対策としても、実務知識としても役立つ内容を目指します。
なぜDNSにセキュリティが必要なのか？（DNSの脆弱性）
DNSSECを理解するためには、まず「なぜDNSSECが必要になったのか」、つまりDNSが本来抱えている弱点について知る必要があります。
インターネットの電話帳「DNS」の仕組み
私たちがWebブラウザに「google.co.jp」と入力すると、裏側ではDNSサーバーに対して「このドメインのIPアドレス（Webサーバーの場所）を教えて」という問い合わせが行われます。この時、私たちのパソコン（スタブリゾルバ）は、社内やプロバイダ（ISP）が用意したキャッシュDNSサーバー（フルリゾルバ）に質問を投げます。
キャッシュDNSサーバーは、世界中のDNSサーバー（権威DNSサーバー）に問い合わせを行い、見つけ出したIPアドレスをパソコンに返答します。この際、毎回問い合わせを行うのは効率が悪いため、キャッシュDNSサーバーは一度調べた結果を一定期間保存（キャッシュ）し、同じ質問が来たら手元のキャッシュから即答します。
嘘の情報を教えられる「DNSキャッシュポイズニング」
DNSの通信には、主にUDPというプロトコルが使われます。UDPは「送りっぱなし」の通信であり、相手との接続確認を行わないため高速ですが、送信元の偽装が容易という特徴があります。
DNSキャッシュポイズニングは、この仕組みを悪用した攻撃です。攻撃の流れは以下の通りです。
- 攻撃者は、ユーザーが利用しているキャッシュDNSサーバーに対して、偽のIPアドレス（攻撃者が用意した罠サイト）情報を送りつけます
- キャッシュDNSサーバーが、本物の権威DNSサーバーからの回答よりも先に、攻撃者からの偽の回答を受け取ってしまった場合、それを「正しい情報」としてキャッシュに保存してしまいます
- これを「毒入れ（ポイズニング）」と呼びます。一度毒が入ると、キャッシュの有効期限が切れるまで、そのDNSサーバーを利用するすべてのユーザーは、正規のURLを入力しても罠サイトへ誘導され続けることになります
DNSには「一番最初に届いた回答を無条件に信じる」という性質があるため、攻撃者は「本物より早く回答する」ことさえできれば、攻撃を成功させることができるのです。
脅威を劇的に高めた「カミンスキー攻撃」の衝撃
かつて、キャッシュポイズニングを成功させるのは、タイミングやIDの一致が必要で難しいとされていました。しかし、2008年に発表されたカミンスキー攻撃（Kaminsky Attack）がその前提を覆しました。
通常、キャッシュ済みのドメインには攻撃できません。しかしカミンスキー攻撃では、ターゲットのドメイン（例：example.com）に対して、存在しないサブドメイン（001.example.com、002.example.com…）への問い合わせを大量に行わせます。
キャッシュDNSサーバーはこれらを知らないため、毎回権威サーバーへ問い合わせを行います。攻撃者はその隙に、「example.comの権威サーバー情報はこれだ」という追加情報（グルーレコード）を含んだ偽回答を大量に送りつけます。
これにより、攻撃者は「数打ちゃ当たる」戦法が可能になり、短時間でキャッシュポイズニングを成功させることができるようになりました。従来は攻撃成功率が極めて低かったものが、現実的な脅威へと変貌したのです。
従来の対策（ポートランダマイゼーション）の限界
緊急対策として普及したのがソースポートランダマイゼーションです。問い合わせに使用するポート番号をランダムに変化させることで、攻撃者が回答を偽装する際の「当たり」の組み合わせ（トランザクションID×ポート番号）を数万倍に増やし、確率を下げる手法です。
しかし、これはあくまで確率を下げる対症療法に過ぎません。計算能力の向上や、通信経路の盗聴によって突破されるリスクは残ります。そこで、根本的な解決策としてDNSSECの導入が求められるようになったのです。
DNSSECの仕組み：デジタル署名で「本物」を証明する
DNSSEC（DNS Security Extensions）は、DNS応答の正当性を暗号技術を用いて保証する拡張機能です。誤解しやすいポイントですが、DNSSECは通信の暗号化（盗聴防止）を行うものではありません。ドメイン名やIPアドレスは平文のまま流れます。
その代わり、データにデジタル署名を付加することで、以下の2点を保証します。
- データ出自の認証 : そのデータが、権限を持つ本物の管理者によって作成されたものであること
- データの完全性 : データが通信途中で改ざんされていないこと
署名と検証の基本フロー
DNSSECは公開鍵暗号方式を応用しています。公開鍵暗号方式では、秘密鍵で暗号化（署名）したデータは、対応する公開鍵でのみ検証できるという性質を利用します。
署名側（権威DNSサーバー）は、自身が管理するゾーンのデータ（リソースレコード）に対して、秘密鍵を使ってデジタル署名を作成し、DNS応答と一緒に送ります。検証側（キャッシュDNSサーバー）は、権威DNSサーバーの公開鍵を入手し、送られてきたデータと署名を検証します。
もし攻撃者が偽のIPアドレスを送りつけたとしても、攻撃者はドメイン管理者の秘密鍵を持っていないため、正しい署名を作成できません。検証側は「署名が合わない」と判断し、その情報を破棄（無効化）します。これにより、キャッシュポイズニングを確実に防ぐことができます。
運用負荷を下げる工夫「ZSK」と「KSK」の役割分担
DNSSECでは、通常2種類の鍵ペアを使い分けます。「なぜ1つの鍵ではいけないのか？」という疑問に対する答えは、DNSの運用コスト削減にあります。
ZSK（Zone Signing Key: ゾーン署名鍵）は、ゾーン内のデータ（Aレコードなど）に署名するための鍵です。日常的に使われるため、セキュリティ上、比較的短い期間（例：1～3ヶ月）で交換（ロールオーバー）する必要があります。もしこれを親ゾーン（上位機関）に登録しなければならないとすると、頻繁な申請手続きが発生し大変です。そのため、ZSKは自ドメイン内だけで管理・交換できるように設計されています。
KSK（Key Signing Key: 鍵署名鍵）は、ZSKそのもの（DNSKEYレコード）に署名するための「鍵を守るための鍵」です。親ゾーンに登録するのは、このKSKの情報（ハッシュ値）だけです。KSKの交換サイクルを長く（例：1年～数年）設定することで、親ゾーンへの変更申請の手間を最小限に抑えています。
この二重構造により、「日常的なセキュリティ維持（ZSK）」と「親子間の信頼関係（KSK）」を分離し、運用効率を高めているのです。
信頼の連鎖（Chain of Trust）とトラストアンカー
「公開鍵を使って署名を検証する」と言いましたが、そもそも「入手した公開鍵が本物である」ことは誰が保証するのでしょうか？もし公開鍵ごと偽物にすり替えられていたら、検証は成功してしまいます。これを解決するのが信頼の連鎖（Chain of Trust）です。DNSの階層構造を利用して、上位が下位を保証していく仕組みです。
親が子を証明するバケツリレー
信頼の連鎖は、以下のように機能します。
- 子ゾーン（example.jp）: 自分のKSKのハッシュ値を親ゾーンに渡します
- 親ゾーン（.jp）: 受け取ったハッシュ値をDSレコードとして登録し、自身の秘密鍵で署名します。これにより「.jp」は「example.jpの鍵はこれだ」と保証します
- さらに上の親（ルートゾーン）: 同様に「.jp」の鍵を保証します
このように、検証側はルートゾーンから順に署名を辿っていくことで、最終的に末端のドメイン情報の正しさを確認できます。この連鎖が途切れると、DNSSECの検証は失敗します。
信頼の起点「トラストアンカー」の自動更新（RFC 5011）
信頼の連鎖を辿るには、一番上のルートゾーンの公開鍵だけは、あらかじめ「絶対に正しいもの」としてキャッシュDNSサーバーが持っていなければなりません。これをトラストアンカーと呼びます。
では、ルートゾーンの鍵が更新されたらどうなるでしょうか？世界中のサーバー管理者が手動で設定変更するのは非現実的です。そこでRFC 5011という仕組みが使われます。これは、古い鍵（信頼済み）を使って新しい鍵を署名し、一定期間（ホールドダウンタイム）並行運用することで、自動かつ安全にトラストアンカーを更新するプロトコルです。
この仕組みにより、世界中のDNSサーバーは人手を介さずに新しい鍵へ移行でき、インターネット全体のセキュリティを維持しながら鍵の更新が可能になっています。
試験に出る！DNSSEC専用のリソースレコード徹底解説
DNSSECを導入すると、従来のリソースレコードに加え、セキュリティ用の新しいレコードが登場します。情報処理安全確保支援士試験では、これらの中身と役割が頻出です。
RRSIG（Resource Record Signature）
リソースレコード署名。これが「デジタル署名」の実体です。AレコードやMXレコードなどのセットごとに作成されます。中には「署名の有効期限（開始・終了日時）」が含まれており、期限切れの署名は無効となります。これにより、古い情報を再送する「リプレイ攻撃」を防ぎます。
RRSIGレコードには、署名対象のレコードタイプ、使用したアルゴリズム、署名者の名前、署名の有効期間などの情報が含まれており、検証側はこれらの情報を元に署名の正当性を確認します。
DNSKEY（DNS Public Key）
DNS公開鍵。そのゾーンのZSKとKSKの公開鍵情報が記述されています。フラグフィールド（数値）を見ることで、それがZSKなのかKSKなのかを判別できます（一般的に256がZSK、257がKSK）。
DNSKEYレコードには、公開鍵の実体だけでなく、使用する暗号アルゴリズムの情報も含まれています。検証側は、このDNSKEYレコードを使ってRRSIGの署名を検証します。
DS（Delegation Signer）
委任署名。これは親ゾーンに登録されるレコードです。子ゾーンのKSKのハッシュ値（指紋）が含まれています。親ゾーンがこのDSレコードに署名することで、子ゾーンへの委任の正当性を証明し、信頼の連鎖を繋ぎます。
DSレコードは、子ゾーンのKSKの公開鍵そのものではなく、そのハッシュ値を持つことで、レコードサイズを小さく保ちながら、子ゾーンの鍵の真正性を保証しています。
NSECとNSEC3：「存在しない」ことを証明する悪魔の証明
DNSでは「そのドメインは存在しない（NXDOMAIN）」という回答も、嘘偽りないことを証明しなくてはなりません。そうしないと、攻撃者が「そのサイトは無いよ」と嘘をついてアクセスを妨害できてしまうからです。
しかし、「無い」ことを証明するために、存在しない無限のドメイン名に署名することは不可能です。そこで、「ある」ものを並べて間接的に証明します。
NSEC（Next Secure）は、存在するドメインを辞書順に並べ、「apple.jpの次はbanana.jpです」と答えます。もしapricot.jpを問い合わせてこの回答が来れば、「appleとbananaの間には何もない＝apricotは存在しない」ことが証明されます。ただし、弱点（ゾーン列挙）があり、ドメイン名がそのまま書かれているため、順に辿っていくことでゾーン内の全ドメインリストがバレてしまう（ゾーン列挙攻撃）リスクがあります。
NSEC3は、ドメイン名をハッシュ化してから順序付けを行います。「ハッシュ値Aの次はハッシュ値B」と示すことで、元のドメイン名を隠しつつ、不在証明を行います。これによりゾーン列挙を防ぎます。NSEC3は、ハッシュ計算のコストがかかりますが、プライバシー保護の観点から推奨される方式です。
具体的な名前解決のフローとトラブル時の挙動
正常な検証プロセス
ユーザーがwww.example.jpにアクセスしようとした時、キャッシュDNSサーバーは以下の動きをします。
- DOビットを設定: 問い合わせ時に「DNSSECの情報もください」というフラグを立てます
- データ取得:
example.jpのAレコードと共に、署名（RRSIG）と公開鍵（DNSKEY）を取得します - 署名検証: 公開鍵を使って署名を検証し、改ざんがないか確認します
- 連鎖確認: 親ゾーン（
.jp）に問い合わせてDSレコードを取得し、example.jpの鍵が本物か確認します。これをルートゾーンまで繰り返します - 回答: 全て成功したら、ユーザーにIPアドレスを返します。この時、ADビット（Authenticated Data）を立てて「検証済み」であることを伝えます
検証失敗時の挙動「SERVFAIL」
もし署名が不正だったり、期限切れだったりした場合、キャッシュDNSサーバーはどうするのでしょうか？この場合、ユーザーには偽のIPアドレスを絶対に渡してはいけません。そのため、IPアドレスの代わりにエラーコード SERVFAIL（Server Failure） を返します。
ユーザーのブラウザには「サーバーが見つかりません」と表示されます。一見すると障害に見えますが、これこそが「ユーザーを偽サイトから守った」というDNSSECの防御成功の証なのです。
実際の運用では、このSERVFAILが頻発する場合、以下のような原因が考えられます。
- 署名の有効期限が切れている（鍵のロールオーバーに失敗）
- 親ゾーンのDSレコードと子ゾーンのKSKが一致していない
- ネットワーク機器がEDNS0に対応していない
- 時刻同期のずれによる署名の期限エラー
これらのトラブルシューティングには、digコマンドに+dnssecオプションを付けて、実際に返されるレコードを確認することが有効です。
DNSSEC導入の壁と運用上の課題
DNSSECは強力なセキュリティ技術ですが、導入にはいくつかのハードルがあり、すべてのドメインで普及しているわけではありません。
「パケットが大きすぎる」問題とEDNS0
従来のDNSは、パケットサイズの上限を512バイトとしていました。しかし、DNSSECの署名や鍵情報は大きく、これを容易に超過します。そこで、EDNS0という拡張仕様を使い、「もっと大きなパケットでも送っていいよ」と通知する必要があります。
EDNS0は、DNSプロトコルの後方互換性を保ちながら、パケットサイズの拡張やその他の機能追加を可能にする仕組みです。現代のDNSサーバーやリゾルバのほとんどがEDNS0に対応していますが、古い機器では対応していない場合があり、これが導入の障壁になることがあります。
IPフラグメンテーションと通信障害のリスク
大きなパケット（例えば1500バイト以上）が流れると、ネットワーク経路上で分割（IPフラグメンテーション）されることがあります。しかし、セキュリティ設定の厳しいファイアウォールの中には、「分割されたパケットは怪しい」と判断して破棄してしまうものがあります。また、IPv6環境などでは分割処理が原因でパケットが届かないこともあります。
これが「DNSSECを入れたら一部の環境から繋がらなくなった」というトラブルの主原因です。導入時にはネットワーク機器の設定（Path MTUなど）の調整が不可欠です。特に企業ネットワークでは、ファイアウォールやIDS/IPSの設定を見直し、正当なDNSSECパケットを通過させる必要があります。
鍵管理の複雑さと運用コスト
DNSSECでは、ZSKとKSKという2種類の鍵を定期的にローテーションする必要があります。特にKSKの更新では、親ゾーンへのDS レコードの登録変更が必要となり、タイミングを誤ると信頼の連鎖が途切れてしまいます。
鍵のロールオーバーには、「事前公開方式」や「ダブルシグネチャ方式」といった手法があり、それぞれに利点と欠点があります。自動化ツールを使うことで運用負荷を軽減できますが、仕組みを理解せずに運用すると、トラブル時の対応が困難になります。
ラストワンマイル問題：PCとDNSサーバー間は守れない？
DNSSECが保証するのは、「権威DNSサーバー」から「キャッシュDNSサーバー」までの区間です。私たちのPC（スタブリゾルバ）とキャッシュDNSサーバーの間（ラストワンマイル）は、通常DNSSECの検証を行わず、信頼している前提で通信します。
この区間の盗聴や改ざんを防ぐには、DNSSECではなく、DNS over HTTPS（DoH） や DNS over TLS（DoT） といった、通信経路そのものを暗号化する技術を併用する必要があります。最近のブラウザやOSでは、DoH/DoTへの対応が進んでおり、DNSSECと組み合わせることで、より強固なセキュリティを実現できます。
署名の有効期限管理とタイムスタンプ
RRSIGレコードには署名の有効期限が含まれており、この期限を超えると署名は無効となります。これは、古い署名を使った攻撃（リプレイ攻撃）を防ぐための重要な機能ですが、運用上は定期的に署名を更新する必要があります。
また、署名の検証にはシステム時刻が使われるため、サーバーの時刻がずれていると、まだ有効なはずの署名が「期限切れ」と判断されたり、逆に期限切れの署名が「有効」と判断されたりする問題が発生します。NTPによる正確な時刻同期は、DNSSEC運用の必須要件です。
DNSSECの実装状況と今後の展望
世界的な普及状況
DNSSECの普及率は、国や地域によって大きく異なります。特にヨーロッパでは、政府主導でDNSSECの導入が進められており、.nl（オランダ）や.se（スウェーデン）といった国別トップレベルドメインでは高い導入率を誇っています。
日本でも、.jpドメインではDNSSECに対応しており、多くの政府機関や金融機関がDNSSECを導入しています。しかし、中小企業や個人サイトでの普及はまだ限定的です。
Cloudflareなどのサービスによる導入支援
DNSSECの導入ハードルを下げるため、CloudflareやRoute 53などのマネージドDNSサービスでは、ワンクリックでDNSSECを有効化できる機能を提供しています。これらのサービスは、鍵の生成・管理・ローテーションを自動化してくれるため、専門知識がなくても安全にDNSSECを運用できます。
DNSSECの限界と補完技術
DNSSECは「改ざん検知」に特化した技術であり、通信の「機密性」は提供しません。また、DNSクエリの内容自体は平文で流れるため、どのサイトにアクセスしようとしているかという情報は盗聴される可能性があります。
この問題を解決するのが、前述のDoH/DoTです。これらは、DNS通信そのものをHTTPSやTLSで暗号化することで、クエリの内容を隠蔽します。DNSSECとDoH/DoTを組み合わせることで、「改ざん防止」と「盗聴防止」の両方を実現できます。
【演習】DNSSEC・キャッシュポイズニング対策 徹底理解クイズ（全10問）
記事で解説したDNSSECの仕組みや、カミンスキー攻撃の脅威について、知識は定着しましたか？ 情報処理安全確保支援士試験でも頻出の「鍵のロールオーバー（ZSK/KSK）」や「信頼の連鎖（Chain of Trust）」、そして運用時のトラブルシューティングなど、重要なポイントを厳選して問題化しました。 ただ正解するだけでなく、解説を読み込んで「なぜその答えになるのか」を深く理解しましょう。全問正解を目指してチャレンジしてください。
まとめ
DNSSECは、インターネットの根幹であるDNSに「真正性」と「完全性」という信頼をもたらす技術です。公開鍵暗号方式によるデジタル署名と、ルートゾーンを起点とした信頼の連鎖によって、偽のサイトへ誘導されるキャッシュポイズニング攻撃を強力に防ぐことができます。
一方で、パケットサイズの増大によるネットワークトラブルや、厳格な鍵管理といった運用コストも伴います。しかし、インターネット社会の信頼性を担保するためには不可欠な技術であり、JPドメインをはじめとする主要なドメインでは標準的なインフラとなりつつあります。
DNSSECは「改ざん検知」に特化した技術です。通信経路の「暗号化」を行うDoH/DoTなど、他の技術と組み合わせることで、より強固なセキュリティ環境が構築できることを理解しておきましょう。情報処理安全確保支援士試験では、DNSSECの仕組みだけでなく、その限界と補完技術についても問われることがあります。体系的な理解を心がけてください。
次回は、メールのセキュリティに焦点を当てます。私たちが日常的に使うメールプロトコルが抱える根本的な弱点と、なりすましメールの仕組みについて解説します。