DNSSECとは？ わかりやすく10分で解説

DNSSECとは何か？

DNS（Domain Name System）は、私たちが覚えやすいドメイン名（例：example.com）を、コンピューターが通信に使うIPアドレス（例：93.184.216.34 のような A レコードの値）へ変換する仕組みです。いわば「インターネットの電話帳」のような存在で、Web閲覧やメール送信など、日常的な通信の入口になっています。なお、example.com は文書化用途の予約ドメインとして管理されているため、例示としてよく使われます。

DNSが抱えるセキュリティ上の弱点

従来のDNSは、基本的に「その応答が正しいものかどうか」を暗号学的に確認する仕組みを持っていません。そのため、攻撃者が偽のDNS応答を混入できると、利用者をフィッシングサイトへ誘導するなどの被害が起こり得ます（例：DNSキャッシュポイズニング、DNSハイジャック）。

DNSSECの定義

DNSSEC（DNS Security Extensions）は、DNS応答が「改ざんされていないこと（完全性）」と「正当なゾーンから返ってきたこと（起源認証）」を、デジタル署名によって検証できるようにする拡張仕様です。

ここで注意したいのは、DNSSECが保証するのはDNS応答が改ざんされていないこと（完全性）と署名したゾーン運用者に由来すること（データ起源認証）であり、返ってきた回答内容が常に「安全で正しい」ことまでを保証する仕組みではない点です。また、DNSSECは通信内容を暗号化して盗聴を防ぐ（機密性）仕組みでもありません。通信の機密性やプライバシー保護は、DoH や DoT といった暗号化DNSが担う領域になります。

DNSSECが必要とされる理由

DNS応答が攻撃者によって改ざんされると、利用者がURLを正しく入力していても偽サイトへ誘導される可能性があります。DNSSECの検証（バリデーション）を行うリゾルバを利用している場合、DNS応答の署名検証に失敗すると、その応答は不正の可能性があるものとして拒否され、結果として「名前解決できない」挙動になります。これにより、改ざんされた応答をそのまま利用してしまうリスクを下げられます。

DNSSECの歴史と発展

DNSSECの誕生

DNSSECは、DNSの設計上の弱点である「応答の真正性や完全性を検証できない」という課題を補うために標準化が進められてきました。現在では複数のRFCとして仕様が整理され、運用面での知見も積み重ねられています。

代表的な改良点

• 署名検証の連鎖（信頼の連鎖）を前提とした設計の整備
• NSEC / NSEC3 により、存在しない名前（NXDOMAIN 等）に対する応答も検証できる仕組みの導入
• 鍵更新（ロールオーバー）や応答サイズ増大など、運用面を考慮した手順や指針の整備

DNSSECの仕組み

DNSSECでは、DNSゾーン内のレコードセット（RRset）に署名を付与し、受信側（検証を行うリゾルバ）が公開鍵で検証することで、改ざん検知と起源認証を実現します。重要なのは、「どの公開鍵を信頼するか」を親子ゾーンの委任関係に沿ってたどれるようにしている点です。検証側は、起点となるトラストアンカー（多くの環境ではルートゾーンの鍵）を基準に、DS → DNSKEY → RRSIG の順で検証を行います。

DNSSECで追加される主なレコード

• DNSKEY：ゾーンの公開鍵情報（署名検証に使用）
• RRSIG：各 RRset に対するデジタル署名
• DS（Delegation Signer）：親ゾーンに登録される、子ゾーンの鍵情報の要約
• NSEC / NSEC3：存在しない名前に対する応答でも改ざん検知を可能にするための情報

ZSKとKSK

DNSSECでは、運用上の扱いやすさから、鍵を役割ごとに分けて管理するのが一般的です。

• ZSK（Zone Signing Key）：ゾーン内の DNS レコード（RRset）に署名する鍵
• KSK（Key Signing Key）：DNSKEY RRset を署名する鍵で、親ゾーンに登録される DS レコードと対応する

この分離により、レコード署名用の ZSK は比較的頻繁に更新しつつ、信頼連鎖に直接関わる KSK は慎重に更新する、といった運用が行いやすくなります。

署名・検証の流れ（信頼の連鎖）

1. ゾーン運用者が、ゾーン内の RRset に署名し、RRSIG を付与する
2. 権威 DNS サーバーが DNSKEY（公開鍵）を公開する
3. 親ゾーンが、子ゾーンの DNSKEY に対応する DS レコードを保持する
4. 検証リゾルバが、親ゾーンから順に DS → DNSKEY → RRSIG を検証し、DNS応答の真正性と完全性を確認する

DNSSECが「守るもの／守らないもの」

• 守るもの：DNS応答の完全性（改ざん検知）、起源認証（正当なゾーン由来かどうか）
• 守らないもの：通信の機密性（盗聴防止）、DNS自体の可用性（DDoS等による停止）、Webサイト内容の安全性

DNSSECのメリットとデメリット

DNSSECのメリット

• 偽のDNS応答を検知できる：DNS改ざんを起点とするフィッシング誘導への対策になる
• 名前解決の信頼性が高まる：検証リゾルバによって、応答の正当性を判断できる
• 他のセキュリティ対策と役割分担しやすい：HTTPS やメール認証などと組み合わせて使える

DNSSECのデメリット（導入・運用の注意点）

• 運用負荷：鍵管理やロールオーバーを継続的に行う必要がある
• 応答サイズの増加：署名情報により、EDNS0 や TCP フォールバックへの配慮が必要になる場合がある
• 設定ミスの影響：DS レコードの不整合などにより、正当なドメインでも名前解決できなくなることがある

なお、「DNSSECを導入すると負荷分散やトラフィック制御ができなくなる」というよりも、動的な応答を行う環境では、署名と整合させた運用設計が難しくなる場合がある、と整理したほうが実態に近いでしょう。

DNSSECのセットアップと設定

導入の前提チェック

• 権威 DNS サーバーが DNSSEC 署名に対応しているか
• レジストラやレジストリが DS レコード登録に対応しているか
• 鍵管理や監視を含む運用体制を整えられるか

基本的な設定手順（概要）

1. ZSK と KSK（または DNSKEY）を生成する
2. ゾーン内の RRset に署名し、RRSIG を生成する
3. DNSKEY を公開し、親ゾーンに DS レコードを登録する
4. 信頼の連鎖が成立し、検証に成功することを確認する

維持と保守（鍵ロールオーバー）

DNSSECは導入して終わりではありません。鍵の有効期限管理、ロールオーバー手順の確認、署名期限切れや DS 不整合を検知する監視を、継続的に行う必要があります。

DNSSECとネットワークセキュリティ

DNSSECで補える領域

DNSSECは、DNS応答そのものの正当性を担保することで、名前解決の信頼性を高めます。これにより、DNSを起点とした誘導型の攻撃に対する耐性が向上します。

他の対策とどう組み合わせるべきか

DNSSECは単体で完結する対策ではなく、他の仕組みと役割分担して使うことが前提になります。

• 機密性：DoH / DoT
• Web通信の安全性：HTTPS（TLS証明書）、HSTS
• メールのなりすまし対策：SPF / DKIM / DMARC
• 侵入・不正アクセス対策：WAF、ID管理、MFA、EDR

DNSSECの現状と今後

導入が難しいと言われる理由

DNSSECの普及を妨げてきた要因として、鍵管理を中心とする運用負荷や、設定ミス時の影響の大きさ、CDN やマルチ DNS 環境での設計の複雑さが挙げられます。一方で、マネージド DNS の普及により、以前より導入しやすい環境は増えています。

今後の展望

今後は、運用手順の自動化や監視機能の高度化、暗号化DNSやメール認証といった他技術との組み合わせが、より現実的なテーマになります。DNSSECは、DNSの信頼性を支える仕組みとして、他の対策と組み合わさりながら定着していくと考えられます。

まとめ

DNSSECは、DNS応答の起源認証と完全性を、デジタル署名によって検証できるようにする仕組みです。DNSを起点とする攻撃への耐性を高める一方で、鍵管理や設定ミスへの配慮といった運用面の注意も欠かせません。

HTTPS や暗号化 DNS、メール認証などと役割分担しながら、ネットワーク全体の信頼性を支える仕組みとして位置づけると、DNSSECの役割を理解しやすくなるでしょう。

FAQ（よくある質問）

Q. DNSSECは通信を暗号化して盗聴を防げますか？

A. いいえ。DNSSECが提供するのはDNS応答の起源認証と完全性の検証であり、通信内容の暗号化は行いません。盗聴対策はDoHやDoT、TLSが担います。

Q. DNSSECを導入すればフィッシングを完全に防げますか？

A. 完全に防ぐことはできませんが、DNS改ざんを起点とする誘導を検知しやすくなり、被害リスクを下げる効果が期待できます。

Q. DNSSECは誰が検証するのですか？

A. 検証機能を有効にしたDNSリゾルバが行います。利用者が使うリゾルバが検証を行うことで効果が発揮されます。

Q. DNSSECを入れると名前解決が遅くなりますか？

A. 処理は増えますが、キャッシュが効く環境では体感差が小さい場合も多いです。

Q. DNSSECは可用性も高めますか？

A. 直接は高めません。可用性向上には冗長化やAnycast、DDoS対策が必要です。

Q. ZSKとKSKは必ず分ける必要がありますか？

A. 必須ではありませんが、運用上の理由から分けるのが一般的です。

Q. DSレコードが間違っているとどうなりますか？

A. 検証に失敗し、正当なドメインでも名前解決できなくなる可能性があります。

Q. DNSSECとOCSP/CRLは関係がありますか？

A. 対象が異なります。DNSSECはDNS応答、OCSP/CRLは証明書の失効確認を扱います。

Q. DNSSECとDoH/DoTはどちらを使うべきですか？

A. 目的が異なるため、必要に応じて併用します。

Q. 小規模サイトでもDNSSECは必要ですか？

A. 運用負荷とのバランス次第ですが、マネージドDNSを利用できる場合は選択肢になります。