DNSSEC の信頼チェーンと NSEC ウォーキング

DNSSEC が守るのは「機密」ではなく「真正性」

DNSSEC の目的を一言で言うと、DNS 応答が正規のゾーン管理者に由来し、改ざんされていないことを暗号学的に保証することです。守るのは真正性（authenticity）と完全性（integrity）であって、機密性ではありません。応答は暗号化されず、誰でも平文で読めます。ここを取り違えると、後述の NSEC ウォーキング（ゾーンの中身が漏れる問題）が「DNSSEC の欠陥」に見えてしまいますが、そもそも秘匿は守備範囲外なのです。

DNSSEC が解こうとしたのは、キャッシュポイズニングに代表される応答すり替えです。素の DNS は UDP で識別子も狭く、攻撃者が偽の応答を先に返せばリゾルバはそれを信じます。DNSSEC は応答に署名を付け、リゾルバが署名を検証することでこの攻撃を封じます。署名の数学的基盤は 署名方式 を参照してください。

RRSIG・DNSKEY・DS が作る三段の鎖

DNSSEC の信頼チェーンは、署名対象・署名鍵・鍵の委任という三つの役割を別レコードに分けて構成します。

• RRSIG: ある名前・タイプの RRset 単位（同じ名前・同じタイプのレコード群をまとめた集合）に対する署名。個々のレコードではなく集合に署名する点が重要で、これにより一部だけ抜き取る改ざんを防ぎます。署名対象には有効期間（inception/expiration）も含まれ、古い署名の再利用を防ぎます。
• DNSKEY: 署名検証に使う公開鍵を載せるレコード。ゾーンは通常 2 種類の鍵、KSK（Key Signing Key）と ZSK（Zone Signing Key）を持ちます。
• DS（Delegation Signer）: 子ゾーンの KSK のハッシュを、親ゾーンに置くレコード。親が子の鍵を保証する「委任の釘」です。

検証リゾルバは下から上へ鎖をたどります。あるレコードの RRSIG を、ゾーンの ZSK（DNSKEY）で検証する。その ZSK を含む DNSKEY RRset の RRSIG を、同じゾーンの KSK で検証する。その KSK が正しいことを、親ゾーンの DS が保証する。親の DS RRset もまた親の ZSK で署名され…と続き、最終的にルートゾーンの KSKに行き着きます。ルートの KSK だけはどこからも委任されないため、リゾルバにトラストアンカーとして焼き込まれています（PKI のルート CA に相当）。

DS が「ハッシュ」である点が設計の妙です。子の鍵を更新しても、新旧でハッシュが変わるため親に置く DS だけ差し替えればよく、親に公開鍵全体を持たせる必要がありません。子と親の境界をまたぐ唯一の連結点が DS であり、後述するロールオーバーの難所もここに集中します。

KSK と ZSK を分ける理由

なぜ鍵を 2 つに分けるのか。答えは更新頻度と委任コストの非対称性にあります。

ZSK はゾーン内の全レコードに日常的に署名するため、攻撃面を小さく保ちたく、比較的短い鍵で頻繁に交換します。一方 KSK は DNSKEY RRset だけに署名し、その存在は親の DS から指されています。KSK を換えると親の DS も更新しなければならず、親子間の調整（多くはレジストラ経由）と TTL の伝播待ちが発生します。

もし鍵が 1 つだけなら、日常的な鍵交換のたびに毎回この重い親調整が要ります。KSK（めったに換えない・親と連動）と ZSK（頻繁に換える・ゾーン内で完結）を分離することで、日常の鍵更新を親に触れずに回せるのです。これは設計上の 最小権限 と同種の発想で、影響範囲の広い鍵ほど触る頻度を下げています。

ロールオーバー：署名を切らさずに鍵を入れ替える

鍵交換（ロールオーバー）の鉄則は、検証中のリゾルバが古い鍵で署名を確かめている間は、その古い鍵を消さないことです。リゾルバはキャッシュに古い DNSKEY や DS を TTL の間保持しているため、新旧の重複期間を必ず設けます。鍵ごとに定石が違います。

ZSK の Pre-Publish は「鍵を先に見せておき、後から使う」順序です。リゾルバが新 ZSK をキャッシュ済みになってから新鍵で署名すれば、署名を検証できない瞬間が生じません。KSK の Double-Signature は、DNSKEY を新旧両 KSK で署名してどちらの DS を持つリゾルバでも検証できる状態を作り、その上で親の DS を入れ替えます。

ルートゾーンの KSK ロールは特別で、トラストアンカー自体の更新になります。これは RFC 5011 の自動更新（新鍵を旧鍵で署名して公開し、リゾルバが一定期間観測してから信頼する hold-down 方式）で配布されます。手動更新に頼ると、更新漏れのリゾルバが一斉に検証不能になるためです。

不在証明：「ない」ことを署名する難問

DNSSEC の難所が不在証明（authenticated denial of existence）です。「その名前は存在しない（NXDOMAIN）」「その名前にそのタイプはない」という否定の応答にも署名が要ります。しかし素朴にやると、問い合わせのたびに「存在しません」という応答をその場で署名する必要があり、秘密鍵をオンラインのサーバーに置くことになって危険です。DNSSEC は秘密鍵をオフラインに保ったまま事前署名する設計を守るため、別の工夫をしました。

その答えが NSEC です。ゾーン内の全名前を辞書順（canonical order）に並べ、隣り合う 2 つの名前の「すき間」を 1 レコードにして事前署名しておきます。たとえば alpha.example の次が gamma.example なら、alpha の NSEC は「次は gamma」と示します。問い合わせが beta.example なら、alpha と gamma の間に落ちる NSEC を返すだけで「beta は存在しない」を事前署名済みの署名付きで証明できます。NSEC は同時に「この名前にはどのタイプが存在するか」のビットマップも持ち、タイプ不在も示せます。

NSEC ウォーキング：不在証明が招くゾーン漏洩

ここで前述の「機密性は守らない」が牙をむきます。NSEC は隣の名前を平文で指すため、攻撃者は適当な名前を問い合わせて NSEC を受け取り、「次の名前」へジャンプし、そこをまた問い合わせて…と数珠つなぎにゾーン内の全名前を列挙できます。これが **NSEC ウォーキング（zone walking）**です。署名は完全に正しく、暗号は破れていません。NSEC が定義上、隣接名を露出しているだけです。社内ホスト名など、ゾーンの中身を知られたくない場合に問題になります。

緩和策が NSEC3 です。名前を平文で連結する代わりに、各名前をハッシュ化し、ハッシュ値を辞書順に並べてすき間を署名します。返るのは元の名前ではなくハッシュなので、単純なウォーキングでは元の名前が分かりません。さらにソルトと反復回数を加え、辞書総当たりのコストを上げます（パスワードハッシュ と同じ発想です）。

検証リゾルバの動作：トップダウンに鎖をたどる

検証リゾルバ（validating resolver）は、応答を受け取ると次の手順で信頼チェーンを検証します。

1. ルートの DNSKEY を取得し、焼き込み済みトラストアンカー（ルート KSK）と照合
2. ルートの DS（対象 TLD 用）を ルート ZSK の RRSIG で検証
3. TLD の DNSKEY を取得 → その KSK のハッシュが上の DS と一致するか確認
4. TLD の DS（対象ドメイン用）を TLD ZSK の RRSIG で検証
5. ドメインの DNSKEY → KSK が DS と一致、ZSK が DNSKEY RRSIG で有効か確認
6. 目的の RRset（例 A）を ドメイン ZSK の RRSIG で検証、有効期間も確認
7. すべて成立 → AD（Authenticated Data）ビットを立てて応答を返す

各段で「DS のハッシュ＝下位 KSK のハッシュ」「RRSIG が上位の鍵で検証可」を確かめ、一つでも欠ければ SERVFAIL を返します。クライアントから見ると、検証成功は応答ヘッダの AD ビットで示されます。逆に、ゾーンが DNSSEC 未対応なら親に DS がないことを NSEC/NSEC3 で署名付きに証明し、「ここから下は検証対象外」と安全に判定します（これを保証する仕組みがあるからこそ、攻撃者が DS を消して DNSSEC を無効化するダウングレードを防げます）。

まとめ

DNSSEC は各 RRset を RRSIG で署名し、検証鍵を DNSKEY（KSK と ZSK）で公開し、子の KSK を親の DS が保証する三段の鎖を、ルートゾーンのトラストアンカーまで連ねて真正性を保証します。鍵を 2 種に分けるのは、親調整を伴う KSK と日常更新の ZSK で触る頻度を分離するためで、ロールオーバーは ZSK が Pre-Publish、KSK が Double-Signature、そして DS の伝播遅延を待つのが鉄則です。

不在証明は NSEC/NSEC3 が担いますが、機密は守備範囲外のため NSEC は隣接名の平文露出でゾーンウォーキングを許し、NSEC3 もハッシュ化でコストを上げるだけです。検証リゾルバはルートから鎖を下りて各段の DS と RRSIG を確認し、成立すれば AD ビットを立てます。暗号と署名の前提は 暗号の基礎、ハッシュの性質は ハッシュ化と暗号化の違い と合わせて押さえると、DNS の信頼モデル全体が一本の線でつながります。