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

DNSSECとは何か？

DNSSEC（DNS Security Extensions）は、DNS応答が改ざんされていないことと、署名されたゾーンに由来することを検証できるようにする拡張仕様です。DNSそのものを置き換えるのではなく、名前解決の信頼性を高めるために追加されます。

DNS（Domain Name System）は、ドメイン名に対応する各種のリソース情報を管理し、名前解決に使う分散システムです。代表例は、ドメイン名をIPアドレスに対応付ける用途です。Web閲覧やメール送信など、多くの通信はDNSを入口に動いています。example.com は文書化用途の予約ドメインとして管理されているため、例示によく使われます。

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

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

DNSSECの定義

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

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

DNSSECとDoH / DoTの違い

DNSSECとDoH / DoTは混同されがちですが、役割は異なります。DNSSECはDNS応答が改ざんされていないことを検証する仕組みで、DoH / DoTは主に利用者とリゾルバの間のDNS通信経路を暗号化して、盗聴や改ざんのリスクを下げる仕組みです。言い換えると、DNSSECは「応答を検証する仕組み」、DoH / DoTは「通信を保護する仕組み」です。

DNSSECが必要とされる理由

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

DNSSECの歴史と発展

DNSSECの誕生

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

代表的な改良点

• 署名検証の連鎖（信頼の連鎖）を前提とした設計の整備
• NSEC / NSEC3 により、存在しない名前や存在しないタイプに対する応答でも、その否定応答が改ざんされていないかを確かめられる仕組みの導入
• 鍵更新（ロールオーバー）や応答サイズ増大など、運用面を考慮した手順や指針の整備

DNSSECの仕組み

DNSSECでは、DNSゾーン内のレコードセット（RRset）に署名を付与し、受信側の検証リゾルバが公開鍵で検証します。これにより、改ざん検知とデータ起源認証を実現します。重要なのは、どの公開鍵を信頼するかを、親子ゾーンの委任関係に沿ってたどれるようにしている点です。検証側は、起点となるトラストアンカー（多くの環境ではルートゾーンの鍵）から信頼の連鎖をたどり、各階層の DS と DNSKEY の対応を確認したうえで、最後に対象 RRset の 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 の対応をたどり、最終的に対象RRsetの RRSIG を検証して、DNS応答の完全性とデータ起源認証を確認する

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

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

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

DNSSECのメリット

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

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

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

DNSSECを検討しやすいケース

• 公式サイトや認証基盤など、名前解決の信頼性が重要なドメインを運用している
• 権威 DNS、DS レコード登録、監視を継続して運用できる体制がある
• マネージド DNS を利用でき、鍵管理やロールオーバーの負荷を抑えやすい

なお、「DNSSECを導入すると負荷分散やトラフィック制御ができなくなる」と断じるのは正確ではありません。実際には、動的な応答を行う環境では、署名と整合するように運用設計する難度が上がる、と捉えるほうが実態に近いです。

DNSSECの導入手順と運用のポイント

導入の前提チェック

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

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

1. ゾーンで使う DNSKEY を用意する（運用上は ZSK と KSK に分けることが多い）
2. ゾーン内の RRset に署名し、RRSIG を生成する
3. DNSKEY を公開し、親ゾーンに DS レコードを登録する
4. 信頼の連鎖が成立し、検証に成功することを確認する

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

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

導入後に起こりやすい失敗

• DS レコードの不整合：親ゾーン側の DS と子ゾーン側の DNSKEY が対応しないと、正当なドメインでも名前解決に失敗することがある
• 署名期限切れの見落とし：署名の更新監視が弱いと、気づかないうちに検証失敗を招くことがある
• 検証側の前提不足：権威 DNS 側で署名していても、利用者側または利用中の再帰リゾルバが検証しなければ、改ざん検知の効果は利用者側で発揮されない

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. 完全に防ぐことはできませんが、DNSSEC で署名されたゾーンを検証リゾルバ経由で利用している場合、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を利用できる場合は選択肢になります。

Q. 権威DNSサーバーだけがDNSSECに対応していれば十分ですか？

A. 十分ではありません。ゾーンが署名されていても、利用者側または利用中の再帰リゾルバが検証を行わなければ、改ざん検知の効果は利用者側で発揮されません。