DNSSEC ゾーン署名の本番運用｜KSK/ZSK ロールオーバーと検証失敗時の復旧手順

DNSSEC ゾーン署名の構成要素と本番運用の前提

DNSSEC（DNS Security Extensions）は、DNS 応答の真正性と完全性を暗号署名によって保証する仕組みです。権威 DNS サーバーがゾーンデータに署名し、リゾルバーがその署名を検証することで、キャッシュポイズニングや応答改ざんを防ぎます。

本番運用で DNSSEC を導入する際は、「署名の維持」と「ロールオーバー（鍵の更新）」の二点を継続的に管理する必要があります。署名は有効期限付きであり、更新を怠ると正規ゾーンが SERVFAIL を返すようになります。ロールオーバーは親ゾーン（レジストリや上位ゾーン）との連携が必要なため、単純なファイル置き換えとは異なる手順を踏みます。

本記事では BIND を例に手順を示します。PowerDNS や Knot DNS でも概念は共通ですが、設定ファイルの記法は異なります。また、委任元（レジストリや親ゾーン運用者）に DS レコードを登録できる権限があることを前提としています。

KSK と ZSK の役割分担

KSK（Key Signing Key）

KSK はゾーン内の DNSKEY レコードセットに署名するための鍵です。KSK の公開鍵ハッシュが親ゾーンに DS レコードとして登録され、信頼の起点（トラストアンカー）となります。鍵長は一般に 2048 ビット以上の RSA、または P-256 以上の ECDSA が推奨されます。更新頻度は年 1 回程度が一般的ですが、ロールオーバーのたびに親ゾーンへの DS 更新が必要なため、手間がかかります。

ZSK（Zone Signing Key）

ZSK はゾーン内の実際のリソースレコード（A、MX、CNAME など）に署名します。KSK による DNSKEY レコードへの署名チェーンで信頼が保証されるため、ZSK のロールオーバーは親ゾーンへの変更なしに完結します。更新頻度は 30〜90 日程度が多く、KSK より頻繁に入れ替わります。

なお、BIND 9.17 以降は Single-type Keys（KSK・ZSK を兼用する CSK）もサポートしています。ゾーン規模や運用体制に応じて選択できますが、本記事では従来の 2 鍵構成を前提に説明します。

dnssec-policy による自動管理（BIND 9.16 以降）

BIND 9.16 で導入された dnssec-policy は、鍵の生成・署名・ロールオーバーをほぼ自動で管理します。従来の dnssec-keymgr や dnssec-signzone による手動運用は BIND 9.18 以降では非推奨となり、dnssec-policy への移行が公式に推奨されています。

named.conf への設定（想定例）

以下は想定例です。実環境のゾーン名・ディレクトリ構成に合わせて変更してください。

dnssec-policy "example-policy" {
    keys {
        ksk key-directory lifetime P1Y algorithm ecdsap256sha256;
        zsk key-directory lifetime P90D algorithm ecdsap256sha256;
    };
    dnskey-ttl 3600;
    publish-safety PT1H;
    retire-safety PT1H;
    signatures-refresh P5D;
    signatures-validity P14D;
    signatures-validity-dnskey P14D;
    max-zone-ttl 3600;
    zone-propagation-delay PT5M;
    parent-ds-ttl 86400;
    parent-propagation-delay PT1H;
};

zone "example.com" {
    type primary;
    file "db.example.com";
    dnssec-policy "example-policy";
    key-directory "/var/cache/bind/keys";
};

lifetime には ISO 8601 期間表記（P1Y = 1 年、P90D = 90 日）を使います。signatures-validity は署名の有効期間で、これより短い signatures-refresh で再署名がトリガーされます。parent-ds-ttl と parent-propagation-delay は KSK ロールオーバー時の待機時間算出に利用されます。

設定後は rndc reconfig でリロードします。BIND は鍵を自動生成してゾーンへの署名も自動で行います。rndc dnssec -status example.com で現在の鍵状態と次回アクションのタイミングを確認できます。

KSK ロールオーバーの手順と DS レコード更新

dnssec-policy を使用している場合、KSK のロールオーバーは自動でスケジュールされます。ただし、DS レコードの親ゾーンへの登録・削除は自動化できないケースが多く、手動介入が必要です。

ロールオーバーの流れ

• Publish（公開）：新しい KSK が DNSKEY レコードとして公開されます。この時点では古い KSK も引き続き有効です。
• Ready（準備完了）：新しい KSK が親ゾーンに DS 登録できる状態になります。rndc dnssec -status の出力に “waiting for DS” と表示されます。
• DS 更新：レジストリまたは親ゾーン運用者に対して、新しい KSK の DS レコードを登録します。DS レコードの値は dig DNSKEY example.com | dnssec-dsfromkey -f - example.com などで生成できます。
• DS 確認後に移行通知：DS の反映を確認したら、rndc dnssec -rollover -key <KeyID> example.com で BIND にロールオーバー完了を通知します。自動検出ポーリングが設定されている場合は不要です。
• 旧 KSK の撤退：旧 KSK が DNSKEY レコードから削除された後、対応する DS レコードも親ゾーンから削除します。

DS の反映確認は dig DS example.com @<親ゾーンの権威サーバーIP> で行います。TTL が切れるまで古い DS も残るため、伝播を待ってから次のステップに進むことが重要です。

検証失敗時の診断と復旧手順

DNSSEC の検証失敗は SERVFAIL となってエンドユーザーに影響が及ぶため、迅速な診断が求められます。よくある原因と対処を以下に示します。

原因の切り分け

まず検証が失敗しているかどうかを確認します。dig +dnssec example.com で AD ビットが立っているか、あるいは SERVFAIL になっているかを見ます。DNSSEC 検証を無効化した応答を得るには dig +cd example.com（Check Disabled）を使います。+cd でも同じ SERVFAIL が返るなら DNS レコード自体の問題、+cd なしの場合のみ SERVFAIL なら DNSSEC 署名の問題です。

より詳細なデバッグには delv コマンドが有効です。

delv @127.0.0.1 example.com A +rtrace +vtrace +mtrace

オンラインツールとしては Verisign Labs の DNSSEC Debugger や dnsviz.net が有用です。これらは信頼チェーンを視覚的に示し、どのレコードで検証が切れているかを特定しやすくします。

よくある障害パターンと対処

• 署名期限切れ：dnssec-policy の再署名が何らかの理由で停止しているケースです。rndc sign example.com で強制再署名を試みます。BIND のログに鍵ディレクトリの権限エラーがないかあわせて確認してください。
• DS と DNSKEY の不一致：親ゾーンに登録されている DS が、現在のゾーンの DNSKEY と一致しない状態です。ロールオーバー中に手順を誤った場合や、旧鍵を誤って削除した場合に発生します。dig DNSKEY example.com | dnssec-dsfromkey -f - example.com の出力と親ゾーンの DS レコードを突き合わせて確認します。
• NSEC/NSEC3 関連のエラー：ゾーンファイルの更新後に署名が更新されていない場合、存在否定応答が古い署名で返されます。rndc sign または named の再起動で解消するケースが一般的です。

緊急時の DNSSEC 無効化（最終手段）

検証失敗により名前解決が全面停止し、短時間での修復が不可能な場合は、一時的に DNSSEC を無効化することが現実的な選択肢になります。手順は次のとおりです。

• 親ゾーンから DS レコードを削除します（レジストリのコントロールパネルまたは親ゾーン管理者へ依頼）。
• DS の TTL が経過するまで待機します（dig DS example.com @<上位NSのIP> で消えたことを確認）。
• named.conf の dnssec-policy を none に変更して rndc reconfig を実行します。

DS レコードが残ったまま DNSKEY を削除すると、リゾルバーは引き続き署名を期待するため SERVFAIL が継続します。必ず親ゾーンの DS を先に削除することが重要です。

2026 年現行環境での差分と注意点

BIND 9.18 LTS / 9.20 の変更点

Ubuntu 22.04 LTS には BIND 9.18、Ubuntu 24.04 LTS には AppArmor 対応済みの BIND 9.18 が収録されています。RHEL 9 / AlmaLinux 9 / Rocky Linux 9 は BIND 9.16 ベースのパッケージを提供しており、dnssec-policy は利用できますが、rndc dnssec -checkds による DS 反映の自動検出など 9.18 以降限定の機能は使えません。

BIND 9.18 では inline-signing オプションがデフォルト有効に変わったため、ゾーンの署名済みファイル（.signed）が自動生成されます。従来 dnssec-signzone で手動生成した .signed ファイルを直接参照している構成から dnssec-policy に移行する際は、競合が生じないか確認が必要です。

アルゴリズム選択の現状

RSA/SHA-256（Algorithm 8）は依然として広くサポートされていますが、新規ゾーンでは ECDSA P-256/SHA-256（Algorithm 13）が推奨されます。鍵長が短く生成・署名が高速で、応答サイズも削減できます。Ed25519（Algorithm 15）も仕様上は利用可能ですが、一部の古いリゾルバーや HSM との互換性に注意が必要です。既存ゾーンのアルゴリズム移行は、ロールオーバーと同様に新旧アルゴリズムを並走させながら段階的に切り替えます。

自動 DS 提出（CDS/CDNSKEY）への対応状況

BIND 9.18 以降では CDS・CDNSKEY レコードを自動公開する機能があり、対応したレジストリ（.nl、.se など一部の ccTLD）では DS レコードの自動更新が可能です。日本の .jp ドメインでは 2026 年時点で JPRS が CDS 自動取り込みに対応していないため、手動での DS 登録が引き続き必要です。レジストリごとに対応状況が異なるため、運用前に確認してください。

PowerDNS 4.8 以降では pdnsutil コマンドによるゾーン署名管理が整備されています。BIND から移行する際はゾーンデータの AXFR 転送と鍵の再生成が必要になります。Knot DNS 3.x は keymgr コマンドで独立した鍵管理を行います。いずれも BIND の dnssec-policy に相当する自動管理機能を備えていますが、設定ファイルの記法と鍵管理の粒度は異なるため、移行時は公式ドキュメントを参照してください。