DNSSEC（Domain Name System Security Extensions）
概要
DNSSEC（Domain Name System Security Extensions） は、DNS 応答にデジタル署名を付与して、レコードの改ざんがないことと正当な権威サーバーから発行されたことを検証可能にするセキュリティ拡張です。RFC 4033・RFC 4034・RFC 4035（2005年）で現行仕様が定義されており、RFC 6840（2013年）で実装上の明確化、RFC 9364（2023年）で運用上のベストプラクティスが整理されています。
DNS は 1987 年の設計時にセキュリティ機構を持たず、応答の正当性を検証する手段がありませんでした。この脆弱性を突く代表的な攻撃が DNS キャッシュポイズニングです。攻撃者がリゾルバーに偽の DNS 応答を注入すると、ユーザーは正しいドメイン名を入力しても偽のサーバーに誘導されます。2008 年に Dan Kaminsky が発表したキャッシュポイズニング手法は、DNS の構造的な欠陥を広く知らしめ、DNSSEC の普及を加速させました。
DNSSEC は DNS レコードに公開鍵暗号方式の署名を付加し、リゾルバーが応答を受け取った時点で署名を検証します。署名が不正な場合、リゾルバーはその応答を破棄して SERVFAIL を返します。データの「機密性」は提供しません。応答内容は暗号化されず、通信経路上で読み取り可能です。DNSSEC が保証するのは「完全性」と「出自の認証」の 2 点です。
仕組み
DNSSEC は RRSIG・DNSKEY・DS・NSEC/NSEC3 の 4 種類のレコードタイプを追加し、ルートゾーンからの信頼の連鎖で署名を検証します。
DNSSEC のレコードタイプ
DNSSEC は 4 種類のリソースレコードを DNS に追加します。
| レコード | 役割 |
|---|---|
| RRSIG | 各 RRset（同一名・同一タイプのレコード群）に対するデジタル署名 |
| DNSKEY | ゾーンの公開署名鍵（ZSK と KSK の 2 種類） |
| DS | 親ゾーンに登録する子ゾーンの KSK ハッシュ。信頼の連鎖を構成する |
| NSEC / NSEC3 | レコードが存在しないことを証明する（認証付き不在証明） |
ZSK と KSK
DNSSEC 署名には 2 種類の鍵ペアを使います。
ZSK（Zone Signing Key） はゾーン内の各 RRset に署名する鍵です。署名の結果は RRSIG レコードとしてゾーンに配置されます。ZSK は頻繁にローテーションされるため鍵長を短くでき、署名・検証の処理負荷を抑えます。
KSK（Key Signing Key） は DNSKEY RRset（ZSK の公開鍵を含む）に署名する鍵です。KSK の公開鍵ハッシュが親ゾーンの DS レコードに登録されることで、親子間の信頼チェーンが成立します。KSK は長期間使用するため、ZSK より長い鍵長を設定します。
信頼の連鎖（Chain of Trust）
DNSSEC の検証は、DNS の階層構造に沿ってルートゾーンから対象ドメインまでの信頼の連鎖を辿ります。
ルートゾーン（.）
KSK → DNSKEY RRset に署名
DS レコード → .com の KSK ハッシュを保持
↓
.com ゾーン
KSK → DNSKEY RRset に署名
DS レコード → example.com の KSK ハッシュを保持
↓
example.com ゾーン
KSK → DNSKEY RRset に署名
ZSK → A, MX, TXT 等の各 RRset に署名（RRSIG を生成）リゾルバーは次の手順で検証します。
- example.com の A レコードと RRSIG を受け取る
- example.com の DNSKEY（ZSK）を取得し、RRSIG の署名を検証する
- example.com の DNSKEY（KSK）で DNSKEY RRset の RRSIG を検証する
- .com ゾーンの DS レコードと example.com の KSK ハッシュを照合する
- .com の DNSKEY で DS レコードの RRSIG を検証する
- 同様にルートゾーンまで遡り、トラストアンカー（ルート KSK）に到達する
トラストアンカーは DNSSEC 対応リゾルバーにあらかじめ設定されています。ルートゾーンの KSK は ICANN が管理し、2010 年にルートゾーンへの DNSSEC 署名が開始されました。2018 年 10 月 11 日に初めてのルート KSK ロールオーバーが実施され、鍵が更新されています。
認証付き不在証明（NSEC と NSEC3）
存在しないレコードへの問い合わせに対して「存在しない」という事実自体を署名付きで証明する仕組みが NSEC と NSEC3 です。
NSEC は RFC 4034 で定義され、ゾーン内のレコード名を辞書順に並べて「この名前と次の名前の間にはレコードが存在しない」ことを署名付きで返します。ただし NSEC レコードを順に辿ることでゾーン内の全レコード名を列挙できる（ゾーンウォーキング）という問題があります。
NSEC3 は RFC 5155（2008年）で定義された改良版です。レコード名をハッシュ化して順序付けるため、ゾーンウォーキングによる列挙を困難にします。RFC 9276（2022年）で NSEC3 のパラメーター設定に関するガイダンスが追加されています。
確認方法
dig コマンドに +dnssec フラグを付けると、RRSIG レコードを含む DNSSEC 関連の情報が表示されます。
# DNSSEC 署名付きで A レコードを問い合わせる
dig A example.com +dnssec# DNSKEY レコードを確認する
dig DNSKEY example.com# DS レコードを親ゾーンから確認する
dig DS example.comdig DNSKEY example.com の出力例です。
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
example.com. 2690 IN DNSKEY 256 3 13 MjyZielP0Gqn...
example.com. 2690 IN DNSKEY 256 3 13 kxipjoIbNZDs...
example.com. 2690 IN DNSKEY 256 3 13 oJMRESz5E4gY...
example.com. 2690 IN DNSKEY 257 3 13 mdsswUyr3DPW...flags: に ad（Authenticated Data）が含まれていれば DNSSEC 検証に成功しています。DNSKEY の最初の数値フィールドが 256 は ZSK、257 は KSK を示します。
応答ヘッダーの flags に ad（Authenticated Data）フラグがあれば、リゾルバーが DNSSEC 検証に成功したことを示します。ad フラグがない場合は、ゾーンが DNSSEC に対応していないか、検証に失敗しています。
# ad フラグの確認（flags: に "ad" が含まれるかを見る）
dig A example.com +dnssec @8.8.8.8特定のゾーンの DNSSEC 署名状況を詳しく調べるには、DNSKEY と RRSIG の内容を確認します。
# RRSIG レコードの署名期限を確認する
dig RRSIG example.comRRSIG レコードの出力には署名の有効期間（開始日と終了日）が含まれます。期限切れの署名はバリデーションエラーの原因になります。
外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/dns?domain=example.com&type=TXT"{
"success": true,
"data": {
"domain": "example.com",
"records": {
"TXT": [
["v=spf1 -all"]
]
}
},
"error": null,
"meta": { "responseTime": 45 }
}data.records フィールドに各レコードタイプの結果が返ります。DNSSEC の署名検証自体は DNS over HTTPS のリゾルバー側で行われるため、API が正常にレコードを返せば、リゾルバーレベルでの検証は成功しています。
よくある問題
DNSSEC の設定ミスはドメインの名前解決を完全に停止させるリスクがあり、署名の期限切れと DS レコードの不整合が最も危険です。
RRSIG の署名期限切れ
RRSIG には有効期間があり、期限を過ぎた署名はバリデーションに失敗します。自動署名の仕組み（BIND の inline-signing、PowerDNS の pdnsutil など）が正しく動作していないと、署名が更新されずに期限切れとなります。DNSSEC 対応リゾルバー（Google Public DNS、Cloudflare 1.1.1.1 など）は署名の検証に失敗すると SERVFAIL を返すため、そのドメインの名前解決が完全に停止します。
対処法としては、署名の自動更新が動作しているかを監視し、RRSIG の有効期限を定期的に確認します。dig RRSIG example.com で表示される期限を確認し、更新が行われていないことに気づいたら署名プロセスを再起動します。
DS レコードの不整合
ドメインの KSK をロールオーバーした際に、親ゾーン（レジストラ）の DS レコードを更新し忘れると、信頼の連鎖が切れてバリデーションに失敗します。逆に、DNSSEC を無効化したのに DS レコードを削除し忘れた場合も同様の問題が発生します。
KSK のロールオーバー手順には、新しい KSK の DS レコードを親ゾーンに追加してから旧 KSK を削除する「ダブルサイン」期間が必要です。この手順を省略すると名前解決が停止します。
レスポンスサイズの増大
DNSSEC を有効にすると、RRSIG や DNSKEY などの追加レコードにより DNS レスポンスのサイズが増大します。UDP パケットの最大サイズ（通常 1232 バイト、EDNS0 の推奨値）を超えると、TCP へのフォールバックが発生するか、フラグメント化されたパケットがファイアウォールで破棄される場合があります。
DNS Flag Day 2020 では、EDNS バッファサイズを 1232 バイト に制限することが推奨されました。ネットワーク機器やファイアウォールが TCP/53 を遮断している環境では、DNSSEC を有効にした途端に名前解決が不安定になることがあります。
DNSSEC を無効化する際の手順ミス
DNSSEC を無効化する場合は、先にレジストラから DS レコードを削除し、DS レコードの TTL が切れてからゾーンの署名を停止する必要があります。順序を逆にすると、DS レコードが残っている間は署名なしの応答がバリデーションに失敗し、名前解決が停止します。
DNSSEC の普及状況と課題
ルートゾーンと主要な TLD（.com、.net、.org など）は DNSSEC に対応しており、検証インフラは整備されています。しかし個別ドメインの署名率は低く、2026 年初頭の調査でドメイン全体の署名率は約 4.3% にとどまっています。北欧の ccTLD（.se、.no、.dk）は 70〜75% と高い署名率ですが、グローバルではまだ少数派です。
リゾルバー側の検証対応は進んでおり、Google Public DNS（8.8.8.8）と Cloudflare（1.1.1.1）は DNSSEC バリデーションを標準で有効にしています。EU 圏のリゾルバーでは検証率が約 49.4% 、グローバルでは約 35.4% です。
普及が進まない要因として、運用負荷の増加（鍵管理、署名更新の自動化）、設定ミスによるサービス停止リスク、そして DNS の暗号化（DoH / DoT）との役割の重複感が挙げられます。ただし DNSSEC と DoH / DoT は保護する範囲が異なります。DNSSEC はデータの完全性と出自を保証し、DoH / DoT は通信経路の暗号化を担います。両者は補完関係にあり、どちらか一方で代替できるものではありません。