目次
インターネットで「example.com」のようなドメイン名を入力すると、私たちのパソコンやスマートフォンはDNS（Domain Name System）という仕組みを使って、そのドメインに対応するサーバーのIPアドレスを調べにいきます。普段は意識することのない裏方の仕組みですが、実はDNSには大きな弱点があります。それは「返ってきた回答が本物かどうかを確認する手段が、もともと備わっていない」という点です。
この弱点を悪用されると、ユーザーは本来アクセスするはずのサイトとは異なる、偽のサーバーへ誘導されてしまう可能性があります。この問題を解決するために作られたのが、今回紹介する「DNSSEC」です。本記事では、DNSSECの基本的な仕組みから、実際に自分のドメインの設定状況を確認する方法まで、わかりやすく解説します。
DNSSECとは
DNSSEC（Domain Name System Security Extensions）は、DNSの応答が「本物であること」と「途中で改ざんされていないこと」を、暗号技術を使って検証できるようにするための拡張仕様です。
ポイントは、DNSSECが「暗号化」の技術ではないという点です。通信内容を第三者から隠す（盗み見られないようにする）のはHTTPSやTLSの役割であり、DNSSECが担うのはあくまで「認証」、つまり受け取った情報が正規の発行元から届いた、改ざんのないデータであることを証明する役割です。この違いは混同されやすいので、最初に押さえておきたいポイントです。
なぜDNSSECが必要なのか
DNSはインターネット黎明期に設計されたプロトコルで、当時はセキュリティよりも可用性や単純さが優先されていました。そのため、DNSサーバーに問い合わせをした際、返ってきた回答が本当に正しい送信元から来たものかを検証する仕組みが用意されていませんでした。
この弱点を突く代表的な攻撃が、次の2つです。
- DNSスプーフィング：偽のDNS応答を送りつけ、ユーザーを攻撃者の用意したサーバーへ誘導する攻撃
- DNSキャッシュポイズニング：DNSリゾルバー（キャッシュサーバー）に偽の情報を記憶させ、その情報を参照した多数のユーザーをまとめて偽サイトへ誘導する攻撃
これらの攻撃が成立すると、ユーザーは正しいドメイン名を入力しているにもかかわらず、見た目そっくりの偽サイトに誘導され、ID・パスワードやクレジットカード情報を入力してしまう、といった被害につながりかねません。しかも利用者側からは、アドレスバーのドメイン名は正しく見えるため、異変に気づきにくいのが厄介なところです。DNSSECは、こうした「見た目は正しいが中身は偽物」という状況そのものを技術的に防ぐために導入されました。
DNSSECの仕組み
DNSSECの仕組みは、「手紙に電子署名を付けて送る」とイメージするとわかりやすくなります。署名のない手紙は誰が書いたか証明できませんが、電子署名があれば、公開されている鍵を使って「本当にその差出人が書いたものか」「途中で書き換えられていないか」を検証できます。
RRset（リソースレコードセット）への署名
DNSSECでは、同じ名前・同じ種類のDNSレコード（たとえば同じホスト名に紐づく複数のAレコード）をひとまとめにした「RRset」という単位で、まとめて電子署名を行います。個々のレコードを1件ずつ検証するのではなく、セット単位で検証する点がポイントです。
ゾーン署名鍵（ZSK）と鍵署名鍵（KSK）
DNSSECでは、公開鍵暗号方式を使った2種類の鍵ペアが使われます。
- ゾーン署名鍵（ZSK：Zone Signing Key）：各DNSレコードに署名するための鍵。この署名は「RRSIGレコード」として保存されます
- 鍵署名鍵（KSK：Key Signing Key）：ZSK自体（正確にはZSKを含むDNSKEYレコード）に署名するための鍵
なぜ鍵を2種類に分けるのかというと、ZSKは運用上の理由で比較的頻繁に交換（ロールオーバー）する必要がある一方、KSKの交換は影響範囲が大きく手間もかかるためです。役割を分離することで、日常的な鍵の更新作業を安全かつ手軽に行えるようにしています。
DSレコードによる親子ゾーンの連携
ここまでの仕組みだけでは、「そのKSK自体が本物である」ことをまだ証明できません。そこで登場するのが、親ゾーン（たとえば .com や .jp を管理するレジストリ）に登録する「DS（Delegation Signer）レコード」です。DSレコードには、子ゾーン（あなたのドメイン）のKSKをハッシュ化した値が格納されており、親ゾーンがこの情報を公開することで、「この子ゾーンのKSKは正規のものである」という保証を与えます。
チェーン・オブ・トラスト（信頼の連鎖）
この「親が子を保証する」という関係を、ルートゾーン → トップレベルドメイン（.comや.jpなど）→ 個々のドメインへと順番にたどっていくことで、最終的にルートゾーンを起点とした「信頼の連鎖（チェーン・オブ・トラスト）」が成立します。DNSリゾルバーはこの連鎖を1つずつ検証し、途中に矛盾や欠落があれば、その応答を「信頼できない」として拒否します。
DNSSECに関連する主なレコード
DNSSECを理解するうえで登場する代表的なレコードは、次のとおりです。
| レコード | 役割 |
|---|---|
| DNSKEY | ゾーンの公開鍵（ZSKおよびKSK）を格納する |
| RRSIG | RRsetに対する電子署名を格納する |
| DS | 子ゾーンのKSKのハッシュ値を親ゾーンに登録し、信頼の連鎖をつなぐ |
| NSEC / NSEC3 | 「そのレコードが存在しないこと」を暗号的に証明するためのレコード |
このうちNSEC/NSEC3は少しイメージしづらいレコードですが、役割は単純です。通常のDNSでは「該当のレコードが存在しない」という回答には署名のしようがありません（署名する対象データが存在しないため）。そこでNSECは「アルファベット順で次に存在するレコード名」を返すことで、間接的に「その間に該当のレコードは存在しない」ことを証明できるようにしています。
DNSSECのメリット・注意点
::: pros:
- DNSスプーフィングやキャッシュポイズニングなど、DNSの応答を偽装する攻撃を検知・遮断できる
- ルート→TLD→ドメインという信頼の連鎖により、フィッシングサイトへの意図しない誘導リスクを下げられる
- 金融・医療・ECなど、利用者の信頼が重要な業種でセキュリティ姿勢を示す材料になる
- SPFやDKIMなど、DNSに依存する他のセキュリティ機能の信頼性向上にもつながる cons:
- 鍵のロールオーバーやDSレコードの登録を誤ると、ドメイン自体が名前解決できなくなるリスクがある
- 署名情報が加わる分、DNS応答のデータサイズが大きくなり、わずかに応答が重くなることがある
- 世界的に見ても対応済みドメインの割合はまだ限定的で、DNSSEC自体が万能の対策というわけではない
- 通信内容を暗号化するものではないため、DNSクエリの秘匿性を高めたい場合はDNS over HTTPS（DoH）やDNS over TLS（DoT）と併用する必要がある :::
特に注意したいのが、「設定ミスがそのままサイトの障害に直結する」という点です。一般的なセキュリティ機能は、設定を誤っても「セキュリティレベルが下がる」だけで済むことが多いのですが、DNSSECの場合は検証に対応したリゾルバーが署名の不整合を検知すると、そのドメインへの問い合わせ自体をエラー（SERVFAIL）として拒否してしまいます。つまり「一部の設定ミスがそのままサイト全体のアクセス不能につながる」という、他のセキュリティ設定とは少し性質の異なるリスクがあることを理解したうえで導入するのがおすすめです。実際、国内の大手レジストラでもDNSSEC設定の反映不具合により一時的に名前解決が不安定になった事例が報告されており、設定変更後は必ず動作確認を行う習慣をつけておくと安心です。
自分のドメインのDNSSEC設定状況を確認する方法
「自分のドメインでDNSSECが有効になっているか」「正しく設定できているか」は、専門知識がなくても比較的簡単に確認できます。代表的な方法を紹介します。
1. オンラインのDNSSECチェックツールを使う
もっとも手軽なのは、ドメイン名を入力するだけで診断してくれるオンラインツールです。代表的なものに、Verisign社が提供する「DNSSEC Analyzer」があります。ドメイン名を入力するだけで、DSレコード・DNSKEYレコード・RRSIG署名の有効性・信頼の連鎖のどこかに問題がないかを、視覚的にわかりやすく表示してくれます。このほか、DNSSECの対応状況だけを簡易的に「有効／無効」で確認できるチェッカーも複数公開されているので、まずはこうしたツールでざっくり状態を把握するのがおすすめです。
2. digコマンドで自分で調べる
コマンド操作に抵抗がない方は、dig コマンドを使って直接DNSSEC関連のレコードを確認することもできます。
# DNSKEYレコードを確認する
dig +dnssec example.com DNSKEY
# DSレコードを確認する
dig +dnssec example.com DS
# ルートからの検証経路をたどる
dig +dnssec +trace example.com応答の中に RRSIG や ad（Authenticated Data）フラグが含まれていれば、DNSSECによる署名・検証が機能していることを示すサインです。
3. レジストラの管理画面で確認する
ドメインを取得しているレジストラの管理画面に、DNSSECの設定状況を表示する項目が用意されている場合もあります。国内の主要レジストラでもDNSSECの有効化やDSレコードの登録に対応しているところが増えており、管理画面から数クリックで現在の設定状況を確認できることが多いです。判断に迷う場合は、まずレジストラのヘルプページで「DNSSEC」と検索してみるとよいでしょう。
DNSSECは「有効にしたつもり」で終わっていないかどうかが意外と盲点です。DSレコードをレジストラ側に登録し忘れていたり、外部のDNSサービスに乗り換えた後に古いDSレコードが残ったままになっていたりすると、せっかく設定しても信頼の連鎖が途中で切れてしまいます。設定を変更したときは、必ず上記のようなチェックツールで「secure」と表示されるところまで確認する、というのを習慣にしておくと安心です。
DNSSECを有効化する大まかな流れ
DNSSECを実際に導入する際の流れは、おおむね次のようになります。
- DNSゾーン側でDNSSECを有効化する：利用しているDNSサービス（レンタルDNSやクラウドのDNSサービスなど）の管理画面でDNSSECをオンにし、ZSK・KSKの鍵ペアを生成する
- DSレコードをレジストラに登録する：生成されたKSKをもとにしたDSレコードを、ドメインを管理しているレジストラの管理画面から登録する
- 反映を待つ：レジストラから上位のレジストリへDSレコードが伝わり、TTL（有効期間）が経過すると信頼の連鎖が完成する
- チェックツールで検証する：前述のオンラインツールや
digコマンドを使い、「secure」と判定されることを確認する
DNSサーバー（ネームサーバー）の乗り換えとDNSSECの有効化・無効化を同時に行うと、信頼の連鎖が一時的に矛盾した状態になり、名前解決が不安定になることがあります。ネームサーバーを変更する予定がある場合は、事前にDNSSECを一度無効化してから移行し、移行後にあらためて有効化する、といった手順を踏むと安全です。
まとめ
DNSSECは、DNSの応答に電子署名を付与することで、DNSスプーフィングやキャッシュポイズニングといった「なりすまし」型の攻撃からユーザーを守るための仕組みです。ZSK・KSKという2種類の鍵とDSレコードによって、ルートゾーンからあなたのドメインまで続く「信頼の連鎖」が形成され、DNSリゾルバーはこの連鎖をたどって応答の正当性を検証します。
一方で、設定ミスがそのままサイトのアクセス不能につながりうる、通信内容そのものを暗号化するわけではない、といった注意点もあります。導入する際は、オンラインのチェックツールや dig コマンドを使って「本当に正しく設定できているか」を必ず確認しながら進めるようにしましょう。