DNSSECとは？
DNSSEC（Domain Name System Security Extensions）は、DNSレコードセットにデジタル署名を追加する拡張です。検証リゾルバーは、有効な署名と信頼の連鎖を使って署名済みデータを認証し、不正な変更を検出できます。DNSSECはDNSクエリやDNS応答を暗号化しません。DNSSECの仕組み
信頼の連鎖（鍵分離方式の例）:
ルートゾーン (.)
├── ルートKSK（トラストアンカー）がルートのDNSKEY RRsetに署名
└── ルートZSKはルートゾーンの権威あるRRsetに署名（親ゾーン側にある.com用のDS RRsetを含む）
└── DSダイジェストが.comのKSKと一致
├── .comのKSKが.comのDNSKEY RRsetに署名
└── .comのZSKは.comゾーンの権威あるRRsetに署名（親ゾーン側にあるexample.com用のDS RRsetを含む）
└── DSダイジェストがexample.comのKSKと一致
├── example.comのKSKがexample.comのDNSKEY RRsetに署名
└── example.comのZSKはexample.comゾーンの権威あるRRsetに署名
リゾルバーはルートのトラストアンカーを起点に、署名とDSダイジェストを検証します
DNSSECのレコードタイプ
| レコード | 役割 | 説明 |
|---|---|---|
| RRSIG | 署名 | 各リソースレコードセットに対する暗号学的署名 |
| DNSKEY | 公開鍵 | ゾーンのKSKとZSKに対応する公開鍵をDNSに公開し、DNSSEC署名の検証に使われるレコード |
| DS | 委任署名者 | 親ゾーンに置かれ、子ゾーンのKSKに対応するDNSKEYのハッシュを含むレコード |
| NSEC/NSEC3 | 不存在の認証 | レコードが存在しないことを署名付きで証明 |
鍵の種類
| 鍵 | 役割 | ローテーションの目安 |
|---|---|---|
| KSK（鍵署名鍵） | DNSKEYレコードへの署名 | 運用者のポリシーによる（下記参照） |
| ZSK（ゾーン署名鍵） | その他の権威あるRRsetへの署名（委任点のNS RRsetと、委任に伴うグルーアドレスRRsetを除く（[RFC 4035 §2.2](https://www.rfc-editor.org/rfc/rfc4035.html#section-2.2)）） | 運用者のポリシーによる（下記参照） |
ローテーションの時期はKSKの役割と運用者のポリシーによって異なります。親ゾーンのDSレコードに紐付いたKSKを定期的にローテーションする場合、[RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) は1年を妥当な間隔として示しています。トラストアンカーとして使用されるKSKのローテーションには、DNSSEC検証リゾルバーとの調整が必要で、有効期間を大幅に長くする場合があります（[RFC 6781 §3.2.2](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.2.2)）。
ZSKの有効期間も運用者のポリシーとロールオーバーの制約によって決まります。オンラインで保管し、侵害のリスクが比較的高いZSKでは、[RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) は1か月を目安とすることが妥当としています。これは条件付きの指針で、常に適用される期間ではありません。ロールオーバーでは、TTL、伝播にかかる時間、古い署名がキャッシュから失効するまでの時間を考慮します（[RFC 7583 §3.2.1](https://www.rfc-editor.org/rfc/rfc7583.html#section-3.2.1)）。
2026年10月11日のルートKSKロールオーバー
ICANNはルートゾーンのKSKロールオーバーを2026年10月11日に予定しています。DNSSEC検証リゾルバーのトラストアンカー設定にKSK-2024（キータグ 38696）が登録されていることを確認してください。自動更新が成功したと想定しないでください。キーが見つからない場合は、自動更新が有効になっていることを確認し、利用中のリゾルバーのベンダーの手順に従ってトラストアンカーを更新してください。最新情報は[ICANNのルートKSKロールオーバー案内](https://www.icann.org/resources/pages/ksk-rollover-en)を参照してください。
DNSSECの検証プロセス
1. クライアントがDNSリゾルバーにexample.comのAレコードを問い合わせる
2. リゾルバーがAレコードとRRSIG署名を取得する
3. リゾルバーがRRSIGの検証に使うDNSKEYを取得する
4. リゾルバーがDNSKEYと照合してDSレコードを検証する
5. 信頼の連鎖をルートまでたどり、各段階を検証する
6. すべての署名が有効なら、応答は認証される
DNSSEC検証で検出できる可能性がある問題
以下の検証には、署名付きRRset、検証リゾルバー、途切れていない信頼の連鎖が必要です。署名されていないデータや安全でないと分類されたデータは認証できません。
| 脅威 | 例 | DNSSECによる保護 |
|---|---|---|
| キャッシュポイズニング | 偽のDNSデータをリゾルバーのキャッシュに挿入する | 検証リゾルバーは、署名または信頼の連鎖の検証に失敗するデータを拒否できます。 |
| 応答の改ざん | 署名済みDNSレコードセットを通信中に変更する | 変更されたデータは署名検証に失敗します。 |
| DNSスプーフィング | 署名済みゾーンに偽の応答を返す | 検証リゾルバーは、検証に失敗する応答を拒否できます。 |
導入時の考慮事項
- 性能: 署名によって応答サイズが大きくなる（目安として約1,000～4,000バイト、署名なしでは約100バイト）
- 鍵管理: 鍵を安全に生成、保管し、ローテーションする必要がある
- ゾーン署名: レコードが変更された際にゾーンを再署名する必要がある
- リゾルバーの対応: クライアントはDNSSEC検証を行うリゾルバーを利用する必要がある
ベストプラクティス
1. DNSSEC署名アルゴリズムを選ぶ: [IANAのDNSSECアルゴリズム登録簿](https://www.iana.org/assignments/dns-sec-alg-numbers)では、ECDSAP256SHA256（アルゴリズム13）が署名と検証に推奨されています。192ビットのセキュリティ強度が必要な用途では、ECDSAP384SHA384（14）を使用できる場合があります。アルゴリズムを変更する前に、リゾルバーの対応状況を確認してください（[RFC 9904](https://www.rfc-editor.org/rfc/rfc9904.html)、[RFC 8624 §3.1](https://www.rfc-editor.org/rfc/rfc8624.html#section-3.1)）。
2. 鍵のローテーションを自動化する: OpenDNSSECのようなツールで鍵のライフサイクルを管理する
3. 署名の有効期限を監視する: RRSIG署名には有効期間がある
4. 導入前にテストする: dnsviz.netのようなツールでゾーンを検証する
5. 緊急時に備える: 鍵のロールオーバー手順を文書化する
検証リゾルバーが信頼の連鎖を検証すると、DNSSECは署名済みDNSデータの送信元と完全性を認証します。ただし、返されたアドレスにあるウェブサイトやサーバーの信頼性を保証するものではありません。