DoT（DNS over TLS）の鍵ローテーションは、一度きりの入れ替え作業ではなく、決まった周期で繰り返す運用として組み立てると止まりにくくなります。要点は、今使っている鍵（現行鍵）のほかに、次に使う鍵（次期鍵）を前もって作り、そのピンをクライアントに配っておくことです。こうしておけば、定期の切り替えも、鍵が漏れたときの緊急の切り替えも、クライアントの設定を待たずに進められます。この記事では、Unbound で DoT を提供している構成を例に、ローテーションの周期の決め方、1回分の手順、複数台での進め方、セッションチケット鍵の扱い、監視までを説明します。
証明書と鍵を1回入れ替える作業そのもの（バックアップ、反映、切り戻し）は、この記事でも要所に触れますが、主題は「繰り返し回す仕組み」です。
ローテーションの対象と周期
DoT のサーバーで周期的に入れ替えるものは3つあり、周期がそれぞれ違います。
- サーバー証明書。 有効期限が来るたびに更新します。業界団体（CA/Browser Forum）の決定により、公的な認証局が発行する証明書の最長有効期間は段階的に短くなっていて、Let's Encrypt も有効期間を短くする計画を公表しています（2026年10月現在）。証明書の更新は自動化が前提です。
- サーバーの秘密鍵。 証明書を更新するたびに変える必要はありません。組織のルールで決めた周期（例えば年に1回）と、漏えいの疑いがあるときに入れ替えます。
- TLS セッションチケット鍵。 再接続を速くするための鍵で、設定している場合は日単位などの短い周期で入れ替えます。
このうち、クライアントの側に影響が出るのは秘密鍵の入れ替えだけです。証明書の名前（ホスト名）で接続先を確かめるクライアント（systemd-resolved、Android のプライベート DNS、Unbound の転送設定など）は、同じ名前の有効な証明書であれば鍵が変わっても気にしません。影響を受けるのは、stubby などで公開鍵のピン（SPKI ピン）を設定しているクライアントです。
現行鍵と次期鍵の2本立てにする
DoT のピン留めを定めた RFC 7858 は、ピンを設定するときは予備のピンも含めることを勧めています。これを運用に落とし込むと、次の形になります。
- サーバーは現行鍵で動いている
- 次期鍵はすでに作ってあり、安全な場所に保管している
- クライアントには、現行鍵と次期鍵の2つのピンを配ってある
ローテーションの1回は、「次期鍵を現行鍵に昇格させ、新しい次期鍵を作り、ピンの組を更新する」という操作になります。
現行鍵 次期鍵 クライアントのピン
第1期 K1 K2 K1, K2
第2期 K2 K3 K2, K3 ← K2 に切り替えてから K3 を配る
第3期 K3 K4 K3, K4切り替えの時点で、クライアントはすでに K2 のピンを持っています。そのため、サーバー側を先に切り替えても接続は切れません。ピンの更新（K1 を外して K3 を足す）は、切り替えのあと時間をかけて配ればよくなります。
1回分のローテーション手順
手順1：切り替え前の状態を記録する
作業の前に、設定と鍵のディレクトリのバックアップを取り、各サーバーが今どの鍵で応答しているかを外から記録します。
# サーバーが出している鍵のピン（SHA-256 を Base64 にしたもの）
openssl s_client -connect 192.0.2.53:853 -servername dns.example.com </dev/null 2>/dev/null \
| openssl x509 -pubkey -noout \
| openssl pkey -pubin -outform der \
| openssl dgst -sha256 -binary | openssl enc -base64複数台ある場合は、ホスト名ではなく各サーバーの IP を指定して1台ずつ確かめます。ロードバランサーやエニーキャストの後ろでは、ホスト名で接続するとどの台に当たったか分からないからです。
手順2：次期鍵で証明書を取る
次期鍵はピンをすでに配ってある鍵なので、その鍵を使って証明書を取る必要があります。certbot の通常の更新は鍵を作り直すか今の鍵を使い続けるかの選択になるため、次期鍵から CSR を作り、CSR を受け付ける ACME クライアントの機能（certbot の --csr など）で証明書を取ります。
sudo openssl req -new -key /etc/unbound/tls/keys/k2.pem \
-subj "/CN=dns.example.com" -addext "subjectAltName=DNS:dns.example.com" \
-out /root/dns-k2.csrオプションの組み合わせは ACME クライアントやそのバージョンで変わるので、使っているクライアントの文書で確かめてください。CSR で取った証明書は自動更新の対象から外れることがあるため、次期鍵に切り替えたあとの通常の更新（同じ鍵での更新）をどう回すかも、ここで決めておきます。
手順3：1台ずつ切り替える
複数台で DoT を提供している場合は、全台を同時に切り替えず、1台ずつ進めます。
- 対象の台をロードバランサーやエニーキャストの経路から外す
- 新しい証明書（中間証明書を含む fullchain）と次期鍵を置き、鍵と証明書が対応しているかを確かめる
unbound-checkconfで設定を確かめてから Unbound を再起動する- 手順1のコマンドで、その台が新しいピンで応答していることを確かめる
- 経路に戻し、次の台に進む
# 鍵と証明書の対応（2つの出力が一致すること）
openssl x509 -in fullchain.pem -pubkey -noout | openssl sha256
openssl pkey -in privkey.pem -pubout | openssl sha256切り替えの途中は、現行鍵の台と次期鍵の台が混在します。クライアントは両方のピンを持っているので問題になりません。逆に言えば、ピンの配布が終わっていないクライアントがいる状態で始めると、新しい鍵の台に当たったときだけ失敗する、という分かりにくい症状になります。
手順4：新しい次期鍵を作り、ピンの組を更新する
全台の切り替えが済んだら、新しい次期鍵を作り、ピンの組を「新しい現行鍵、新しい次期鍵」に更新して配ります。
sudo openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 \
-out /etc/unbound/tls/keys/k3.pem
sudo chmod 600 /etc/unbound/tls/keys/k3.pem
sudo openssl pkey -in /etc/unbound/tls/keys/k3.pem -pubout -outform der \
| openssl dgst -sha256 -binary | openssl enc -base64次期鍵は、稼働中のサーバーとは別の場所（鍵の保管用のシステムや、アクセスを絞った管理サーバーなど）に置くと、サーバーが侵害されたときに次期鍵まで一緒に漏れる事態を避けられます。古い鍵は、切り戻しの必要がなくなった時点で削除します。
鍵が漏れたときの緊急ローテーション
2本立てにしておく最大の利点は、緊急時に効きます。現行鍵の漏えいが疑われたら、次期鍵への切り替え（手順2と3）をすぐに行えます。クライアントは次期鍵のピンを持っているので、配布を待つ必要がありません。切り替えたら、漏れた鍵の証明書の失効を認証局に申請し、漏れた鍵のピンをクライアントから外す配布を急ぎます。
次期鍵まで漏れていた場合は、ピン留めしたクライアントの設定を作り直すしかありません。次期鍵を稼働中のサーバーに置かない理由はここにあります。
セッションチケット鍵の扱い
Unbound では、tls-session-ticket-keys を設定した場合だけ、セッションチケット鍵を自分で管理することになります。80 バイトの乱数のファイルを指定し、最初に書いたファイルが新しいチケットの暗号化に、残りは既存のチケットの復号に使われます。
# 新しいチケット鍵を作る例
sudo dd if=/dev/urandom of=/etc/unbound/tls/ticket-new.key bs=1 count=80
sudo chmod 600 /etc/unbound/tls/ticket-new.key周期的に入れ替えるなら、新しい鍵を先頭に、ひとつ前の鍵を2番目に置き、それより古い鍵は外します。入れ替えには Unbound の再読み込みか再起動が必要になるため、systemd のタイマーなどで決まった時刻に実行します。
設定しなければ、Unbound は TLS ライブラリの既定の動作に任せ、プロセスごとに鍵が作られます。複数台でチケットを共有したい特別な理由がなければ、設定しないほうが管理する鍵が減り、漏えいの心配も小さくなります。どちらの動作になるかの詳細は、手元のバージョンの man unbound.conf で確かめてください。
周期を守るための監視
ローテーションは、忘れたころに止まります。次の3つを定期的に確かめる仕組みを用意しておきます。
- 証明書の残り日数。
openssl s_clientで取得した証明書のnotAfterを見て、一定の日数を切ったら通知します。 - 応答している鍵のピン。 手順1のコマンドを各台の IP に対して実行し、結果が配布中のピンの組（現行鍵と次期鍵）のどちらかに一致するかを確かめます。一致しない台があれば、取り違えや古い鍵の読み込みが起きています。
- 次期鍵の存在。 昇格のあとに新しい次期鍵を作り忘れると、次の緊急時に予備がありません。保管場所に次期鍵があり、そのピンが配布済みかを確認項目に入れます。
まとめ
- DoT の鍵ローテーションは、証明書、秘密鍵、セッションチケット鍵で周期が違います。クライアントに影響するのは秘密鍵の入れ替えで、ピン留めしたクライアントだけが対象です。
- 現行鍵と次期鍵の2本立てにし、クライアントには両方のピンを配っておきます。切り替えは次期鍵の昇格と、新しい次期鍵のピンの配布で1回分です。
- 複数台では IP を指定して1台ずつ切り替え、応答している鍵のピンを外から確かめます。
- 次期鍵を稼働中のサーバーとは別に保管しておくと、漏えい時にすぐ切り替えられます。
- セッションチケット鍵は、共有する理由がなければ設定せずに済ませるのが簡単です。設定するなら、新しい鍵を先頭に置く形で定期的に入れ替えます。