2008年7月、セキュリティ研究者のダン・カミンスキーは、世界中のほぼ全てのウェブサイトへのトラフィックを攻撃者が即座に乗っ取ることができるDNSの深刻な脆弱性を発表しました。

インターネットの信頼を揺るがした脆弱性

ブラウザにWebアドレスを入力した際、コンピュータはDNSリゾルバを使用してドメイン名をIPアドレスに変換します。この変換処理の基本については、DNSの仕組みについての解説記事をご覧ください。

1983年に設計された従来のDNSプロトコルには、応答データが本物であるかを確認する認証メカニズムが含まれていませんでした。

カミンスキーの発見（CVE-2008-1447）以前、DNSキャッシュサーバーは16ビットのトランザクションIDのみに依存して応答を識別していました。攻撃者は偽造した応答パケットを大量に送信することで、IDを推測して正解させることが可能でした。一度成功すると、キャッシュサーバーに偽のIPアドレスが書き込まれ、そのサーバーを利用するユーザー全員が偽サイトへ誘導されてしまいます。

この攻撃手法は「DNSキャッシュポイズニング」と呼ばれます。IPスプーフィングなどの手法と組み合わされることで、ユーザーに気づかれることなくトラフィックを横取りする極めて危険な攻撃手法でした。

この課題を根本から解決するために、IETF（Internet Engineering Task Force）は2005年3月にRFC 4033、RFC 4034、RFC 4035として「DNSSEC（Domain Name System Security Extensions）」を標準化しました。

DNSSECのコア：電子署名による本人確認

DNSSECは、DNS通信の内容そのものを暗号化して盗聴を防ぐ技術ではありません。通信相手や閲覧履歴を隠すことが目的の場合は、DNS over HTTPSなどの暗号化技術を使用します。

DNSSECの目的は**「正当性の証明」**です。受け取ったDNS応答が、改ざんされずに本物の権威DNSサーバーから送信されたものであることを保証します。

この仕組みは公開鍵暗号基盤に基づいています。ドメイン所有者は秘密鍵を使ってDNSレコードに電子署名を施し、世界中のリゾルバは公開鍵を使ってその署名を検証します。

検証処理が各階層のサーバー間でどのように行われるか、以下の図で確認してみましょう。

リゾルバが署名の検証に成功した場合のみ、正当なIPアドレスとしてクライアントに返答されます。

DNSSECを構成する主要レコード

DNSSECは既存のAレコードやAAAAレコードを置き換えるのではなく、セキュリティ検証用の新しいレコードを追加します。

RRSIG（Resource Record Signature）: 実際の電子署名データです。同じ種類のレコードセット（RRset）に対してゾーンの秘密鍵で署名を作成します。
DNSKEY: 署名を検証するための公開鍵です。ゾーン署名鍵（ZSK）と鍵署名鍵（KSK）に分かれます。
DS（Delegation Signer）: 親ゾーン（.comや.jpなど）に配置され、子ゾーンのDNSKEYのハッシュ値を保持することで、階層間の信頼をつなぎます。
NSEC / NSEC3: 「指定されたドメインが存在しないこと」を暗号学的に証明し、偽の不在応答による攻撃を防ぎます。

これらのレコードが連携することで、ドメインの信頼性が段階的に検証されます。

信頼の連鎖とルート鍵署名式

公開鍵自体が偽物であれば意味がありません。そこで重要になるのが「信頼の連鎖（Chain of Trust）」です。

たとえば example.com を検証する場合：

リゾルバは example.com の権威サーバーからRRSIGとDNSKEYを取得します。
その公開鍵が正しいか確認するため、上位の .com TLDサーバーにあるDSレコードを照会します。
同様に、.com の鍵を検証するためにルートサーバーのDSレコードを確認します。
最終的な信頼の頂点として**ルート鍵署名鍵（Root KSK）**に到達します。

ルートゾーンより上の権威は存在しないため、ルート鍵は無条件で信頼されるアンカーとなります。ICANNはこのルート鍵を保護するため、四半期ごとに「Root KSK Ceremony（ルート鍵署名式）」という厳格な物理手続きを実施しています。

厳重な保管庫（バンカー）でハードウェア・セキュリティ・モジュール（HSM）を使用して鍵の署名が行われます。2018年10月11日には、史上初となるグローバルな「Root KSK Rollover（ルート鍵ロールオーバー）」が実施され、インターネット全体を停止させることなく新しい鍵への移行が完了しました。

この徹底した運用によって、インターネット全体の暗号的信頼が保たれています。

DNSSECが防げる脅威と防げない脅威

DNSSECは強力な検証機能を提供しますが、すべてのセキュリティ問題を解決する万能薬ではありません。

脅威 / 攻撃手法	DNSSECで防げるか	解説
DNSキャッシュポイズニング	防げる	偽の応答には有効なRRSIG署名がないため拒否される
通信途中の応答改ざん	防げる	データの改ざんが行われると署名検証が失敗する
DNS通信の盗聴・プライバシー	防げない	パケット自体は平文のため、DoHやDoTが必要
似せかけたフィッシングドメイン	防げない	攻撃者が取得した別ドメイン上の正当な署名は通過する
Webサーバー自体のハッキング	防げない	DNS層の検証であり、サーバー上の脆弱性は保護できない

防御範囲を正確に把握し、他のセキュリティ対策と組み合わせることが重要です。

なぜDNSSECの普及には時間がかかっているのか？

2005年に標準化された技術でありながら、APNICの調査によると、2024年時点での世界的なDNSSEC検証率は約35%から40%にとどまっています。

普及がゆるやかな背景には、運用上の難しさがあります：

設定ミスのリスク: ドメイン管理者が鍵の更新（ロールオーバー）手順を誤ると、全世界のリゾルバから「検証失敗」と判定され、サイト全体がアクセス不能になるリスクがあります。
パケットサイズの増大: 暗号署名データが付加されることで応答サイズが大きくなり、従来のUDP 512バイト制限を超えるため、TCPへのフォールバックが発生しサーバー負荷が増加します。

現在はクラウドDNSプロバイダによる自動設定機能が普及したことで、安全かつ手軽にDNSSECを導入できる環境が整いつつあります。