2026年6月16日

DNSSEC の鍵ローテーション手順｜ZSK は事前公開、KSK は DS の差し替えを TTL に沿って進める

DNS・名前解決

DNSSEC の鍵ローテーションは、「新しい鍵を先に見せる → キャッシュが入れ替わるまで待つ → 使う鍵を切り替える → 古い鍵が誰のキャッシュにも残っていない時間を待ってから消す」という順番で進めます。ZSK（ゾーン署名鍵）はゾーンの中だけで完結しますが、KSK（鍵署名鍵）は親ゾーンの DS レコードの差し替えが伴うため、レジストラでの作業と待ち時間の管理が中心になります。この記事では、TTL から待ち時間を見積もる方法、ZSK と KSK それぞれの手順、BIND と Knot DNS で自動化する設定、作業中と作業後の確認方法を説明します。

DNS 事業者の乗り換えやレジストラの移管で DNSSEC が壊れたときの復旧は別の記事で扱っているため、ここでは「自分で署名しているゾーンの鍵を、計画的に入れ替える」作業に絞ります。

鍵の種類と、ローテーションが必要になる場面

DNSSEC のゾーンには、役割の違う鍵が置かれます。

ZSK（Zone Signing Key）：ゾーン内の各レコードに署名する鍵です。DNSKEY レコードではフラグ 256 として表示されます。
KSK（Key Signing Key）：DNSKEY のレコードセットだけに署名する鍵です。フラグ 257 で表示され、親ゾーンの DS はこの鍵を指します。
CSK（Combined Signing Key）：1本の鍵で両方の役割を兼ねる構成です。運用は単純になりますが、入れ替えるときは KSK と同じく DS の差し替えが必要です。

ローテーションを行う理由は、主に次の4つです。

運用方針として鍵の使用期間を決めている（定期ローテーション）
秘密鍵が漏れた、または漏れた疑いがある（緊急ローテーション）
署名アルゴリズムを変更する（例: RSA 系から ECDSA P-256 へ）
署名の仕組みや HSM を入れ替える

定期ローテーションの周期に決まった正解はありません。ZSK は数か月ごとに自動で回し、KSK は期限を設けず必要なときだけ替える、という運用も広く見られます。大切なのは、周期よりも「回すときに壊さない手順」を持っていることです。

マネージド DNS を使っている場合

Cloudflare や Amazon Route 53 などのマネージド DNS では、ZSK のローテーションは事業者が自動で行うのが一般的です。KSK についての扱いは事業者によって異なり、Route 53 のように利用者が KSK を作成・管理し、入れ替えも利用者の手順で行う方式もあります（2026年10月現在）。マネージド DNS を使っている場合は、この記事の考え方（DS を先に足し、TTL を待ってから古いものを外す）を前提に、事業者の手順書に沿って進めてください。

作業前に記録する値

ローテーションの待ち時間は、すべて TTL から決まります。作業の前に、次の値を記録しておきます。

# 現在の鍵（フラグ・アルゴリズム・key tag を確認する）
dig +multi example.com DNSKEY

# 親ゾーンに登録されている DS
dig +short example.com DS

# 親ゾーンの権威サーバーに直接聞き、DS の TTL を確認する（.com の例）
dig +norecurse @a.gtld-servers.net example.com DS

# 署名の有効期限（RRSIG の日付）
dig +dnssec example.com SOA

+multi を付けると、DNSKEY の各行の末尾に ; ZSK; alg = ECDSAP256SHA256; key id = 12345 のような説明が付き、どの鍵がどれかを見分けやすくなります。この key id（key tag）は、DS や RRSIG に書かれた番号と照合するときに使います。

記録するべき待ち時間の要素は次のとおりです。

DNSKEY の TTL：新しい鍵を公開してから、全リゾルバーがそれを知るまでの時間の目安
ゾーン内の最大 TTL：古い鍵で作られた署名がキャッシュから消えるまでの時間の目安
親ゾーンの DS の TTL：DS を差し替えてから、古い DS がキャッシュから消えるまでの時間の目安。gTLD では1日程度のことが多いです
伝播の遅れ：セカンダリへのゾーン転送や、レジストリが DS を反映するまでの時間

実際の待ち時間は、これらに安全のための余裕を足して決めます。計算の考え方は RFC 7583 にまとまっています。

ZSK のローテーション（事前公開方式）

ZSK は、新しい鍵を先に DNSKEY として公開しておき、後から署名に使い始める「事前公開（Pre-Publication）」方式が一般的です。

新しい ZSK を生成し、DNSKEY に追加する。 この時点では署名に使いません。ゾーンには旧 ZSK と新 ZSK の両方が並びます。
DNSKEY の TTL と伝播の遅れの分だけ待つ。 これで、どのリゾルバーのキャッシュにも新 ZSK を含む DNSKEY が入ります。
新 ZSK で署名し直す。 ゾーンの RRSIG が新しい key tag のものに入れ替わります。
ゾーン内の最大 TTL と伝播の遅れの分だけ待つ。 旧 ZSK で作られた署名がキャッシュから消えるのを待ちます。
旧 ZSK を DNSKEY から外す。

よくある失敗は、手順2を飛ばして公開と同時に新しい鍵で署名することです。古い DNSKEY をキャッシュしているリゾルバーは、新しい署名を検証する鍵を持っていないため、SERVFAIL を返します。逆に手順4を飛ばして旧 ZSK を早く外すと、キャッシュに残った古い署名を検証できなくなります。

KSK のローテーション（DS の差し替え）

KSK の入れ替えでは、親ゾーンの DS を切り替える必要があります。自前で署名する場合によく使われるのは、新旧の KSK を一時的に並べる方式です。

新しい KSK を生成し、DNSKEY に追加する。 DNSKEY のレコードセットには、新旧両方の KSK で署名します。
DNSKEY の TTL と伝播の遅れの分だけ待つ。
新しい KSK に対応する DS をレジストラに登録する。 旧 DS と入れ替える方法と、いったん両方を並べる方法がありますが、レジストラの画面で選べる操作に合わせます。
親ゾーンに新しい DS が載ったことを確認する。 親の権威サーバーに直接 dig で問い合わせます。
旧 DS が親ゾーンから消えたあと、親ゾーンの DS の TTL と余裕の分だけ待つ。
旧 KSK を DNSKEY から外す。

新しい DS を登録する値は、署名ソフトウェアが出力するもの、または次のように DNSKEY から計算したものを使います。

# 公開中の DNSKEY から DS を計算する（KSK のみが対象。BIND 付属のツール）
dig +noall +answer example.com DNSKEY | dnssec-dsfromkey -f - example.com

レジストラによっては DS ではなく DNSKEY（公開鍵）の入力を求め、DS を自動で計算します。入力欄の名前や、ダイジェストの種類（SHA-256 が一般的）の選び方は事業者ごとに違うため、レジストラのヘルプで確認してください。

典型的な失敗は、手順4の確認をせずに旧 KSK を外してしまうことです。親ゾーンにまだ旧 DS しかない状態で旧 KSK を外すと、DS が指す鍵がゾーンから消え、検証するリゾルバーすべてで名前解決が止まります。

BIND の dnssec-policy で自動化する

BIND 9.16 以降の dnssec-policy を使うと、鍵の生成から公開、署名の切り替え、削除までを TTL に沿って自動で進められます（BIND 9.18 以降での利用をおすすめします。2026年10月現在）。以前の auto-dnssec は廃止に向かっているため、新しく組むなら dnssec-policy を使います。

// named.conf の例（値は運用に合わせて調整する）
dnssec-policy "rollover" {
    keys {
        ksk lifetime unlimited algorithm ecdsap256sha256;
        zsk lifetime P90D algorithm ecdsap256sha256;
    };
    dnskey-ttl 3600;
    max-zone-ttl 86400;
    parent-ds-ttl 86400;
    parent-propagation-delay 1h;
    publish-safety 1h;
    retire-safety 1h;
};

zone "example.com" {
    type primary;
    file "/var/lib/bind/example.com.db";
    dnssec-policy "rollover";
    inline-signing yes;
};

max-zone-ttl と parent-ds-ttl には、作業前に記録した実際の値を入れます。ここが実際より短いと、BIND は待ち時間を短く見積もってしまいます。inline-signing を明示する必要があるかどうかは BIND のバージョンによって異なるため、使っている版のリファレンスマニュアルで確認してください。

KSK の入れ替えでは、親ゾーンに DS が載ったことを BIND に伝える必要があります。

# 鍵の状態と、次に何を待っているかを表示する
rndc dnssec -status example.com

# 新しい KSK の DS が親に載ったことを伝える（key id は status で確認した番号）
rndc dnssec -checkds -key 23456 published example.com

# 旧 KSK の DS が親から消えたことを伝える
rndc dnssec -checkds -key 12345 withdrawn example.com

# 計画外に鍵を入れ替えたいときは、ロールオーバーを前倒しで開始する
rndc dnssec -rollover -key 34567 example.com

parental-agents で親ゾーンの権威サーバーを指定し、DS の掲載を BIND に自動で確認させる方法もあります。関連する設定項目はバージョンで追加・変更されているため、導入前に該当の版の文書で確かめます。

Knot DNS で自動化する

Knot DNS も、ポリシーを書くと鍵の入れ替えを自動で進めます。KSK の DS 掲載は、指定したリゾルバーに定期的に問い合わせて確認させられます。

# knot.conf の例（抜粋）
remote:
  - id: validator
    address: 9.9.9.9

submission:
  - id: parent_check
    parent: validator
    check-interval: 1h

policy:
  - id: rollover
    algorithm: ecdsap256sha256
    zsk-lifetime: 90d
    ksk-lifetime: 0
    ksk-submission: parent_check

zone:
  - domain: example.com
    dnssec-signing: on
    dnssec-policy: rollover

ksk-lifetime: 0 は KSK を自動で入れ替えない指定です。鍵の一覧は keymgr example.com list、ロールオーバーの手動開始は knotc zone-key-rollover example.com zsk（KSK なら ksk）、DS の登録を手で確認したことを伝えるには knotc zone-ksk-submitted example.com を使います。各項目の既定値や書式はバージョンで変わることがあるため、公式の文書と照らし合わせてください。

CDS / CDNSKEY で DS の更新を自動化する

KSK の入れ替えで手間がかかるのは、レジストラでの DS の登録です。CDS / CDNSKEY レコード（RFC 7344、RFC 8078）を使うと、ゾーンに「次の DS はこれです」と書いておき、親ゾーン側に読み取って更新してもらえます。BIND と Knot DNS はどちらも CDS / CDNSKEY の公開に対応しています。

ただし、親ゾーン側が CDS を読み取るかどうかは TLD とレジストラの組み合わせで決まり、対応状況は変わり続けています（2026年10月現在）。自分のドメインで使えるかを確認するまでは、手作業での登録を前提に手順を組んでおくと安全です。

秘密鍵が漏れたときの緊急ローテーション

漏えいが疑われる場合も、基本の順番は変わりません。待ち時間を省いて古い鍵を即座に外すと、キャッシュの状態によっては自分のドメインが引けなくなります。漏れた鍵で偽の署名が作られる危険と、名前解決が止まる危険の両方を比べ、どこまで待ち時間を縮めるかを判断します。

ふだんから DNSKEY の TTL や DS の TTL を極端に長くしないこと、新しい鍵をいつでも出せるように手順を文書にしておくことが、緊急時の備えになります。

作業中と作業後の確認

各手順のあとに、次の点を確認します。

# 検証付きで引けるか（"fully validated" と表示されれば成功）
delv example.com SOA

# 公開中の DS と DNSKEY から計算した DS が一致しているか
dig +short example.com DS
dig +noall +answer example.com DNSKEY | dnssec-dsfromkey -f - example.com

# すべての NS が同じ鍵と署名を返しているか
for ns in $(dig +short example.com NS); do
  echo "== $ns"; dig +norecurse +multi @"$ns" example.com DNSKEY | grep "key id"
done

外部からの見え方は、DNSViz のような可視化サービスでも確認できます。鍵ごとの状態や DS との対応が図で表示されるため、どの段階で鎖が切れているかを見つけやすくなります。

作業後も、RRSIG の有効期限が近づいていないか、DS とゾーンの KSK が一致しているかを定期的に監視すると、自動化が途中で止まったことに早く気づけます。設定を変更する前には、ゾーンファイルと鍵のディレクトリ、設定ファイルのバックアップを取り、検証用のドメインで一連の流れを試してから本番のゾーンに適用してください。

まとめ

鍵のローテーションは「先に公開 → TTL を待つ → 切り替え → TTL を待つ → 古い鍵を外す」の順で行う
待ち時間は DNSKEY の TTL、ゾーン内の最大 TTL、親ゾーンの DS の TTL、伝播の遅れから見積もる
ZSK は事前公開方式でゾーン内だけで完結し、KSK は親ゾーンでの DS の掲載を確認してから旧 KSK を外す
BIND の dnssec-policy や Knot DNS のポリシーで自動化できるが、KSK では DS の掲載確認を仕組みに組み込む
各手順のあとに delv と dig で検証結果と DS の一致を確かめ、作業後も監視を続ける