Route 53で管理しているドメインでDNSSECのKSKをローテーションする
2025.03.24こんにちは、なおにしです。
Route 53で管理しているドメインでDNSSECのキー署名キー (KSK)をローテーション(ロールオーバー)する機会がありましたのでご紹介します。
はじめに
約1年前の記事でRoute 53で管理しているドメインでDNSSECを有効化してみました。
それからちょうど1年ほど経過したので、KSKをローテーションしてみます。
ドキュメントに記載のとおり、KSKは定期ローテーションすることが推奨になっています。
KSK の削除が必要となる理由の 1 つに、定期的に行うキーのローテーション作業があります。暗号キーについては、定期的にローテーションすることがベストプラクティスです。組織によっては、キーをローテーションさせる頻度に関する標準的な取り決めをしている場合があります。
「定期的に」の部分は組織ごとに決定するものという位置付けなので具体的なタイミングについてAWSのドキュメントには記載がありませんが、RFC 4641には以下のとおり記載されています。
From a purely operational perspective, a reasonable key effectivity period for Key Signing Keys is 13 months, with the intent to replace them after 12 months. An intended key effectivity period of a month is reasonable for Zone Signing Keys.
(機械翻訳)
純粋に運用の観点から見ると、キー署名キーの妥当なキー有効期間は 13 か月で、12 か月後にキーを置き換えることが意図されています。ゾーン署名キーの場合、意図されたキー有効期間は 1 か月が妥当です。
あくまで参考として記載はしたものの、上記はRFCの定義によって推奨されるローテーション間隔というわけではありません。RFC 4641はその後に公開されたRFC 6781によって置き換えられているので、廃止されたものとなります。
- RFC 4641：DNSSEC Operational Practices
- RFC 6781：DNSSEC Operational Practices, Version 2
RFC 6781のAppendixにSummary of Changes from RFC 4641としてまとめられている中に、以下のように記載されています。
Did a significant rewrite of Section 3, whereby the argument is made that the timescales for rollovers are made purely on operational arguments.
（機械翻訳）
第 3 項を大幅に書き直し、ロールオーバーのタイムスケールは純粋に運用上の議論に基づいて決定されると主張しました。
余談ですが、DNSSECに関するRFC内では鍵の「ローテーション」ではなく「ロールオーバー」が正式な用語となっているようです。このため本来はこちらを使うべきかもしれませんが、どちらかというとローテーションの方が聞き馴染みがあることとAWSのドキュメントでの表現に合わせて本記事ではローテーションという表現を使います。
話を戻して、RFC 4641におけるローテーションタイミングの記載ではゾーン署名キー(ZSK)についても言及がありますが、ドキュメントのとおりこちらはRoute 53側で自動的にローテーションしてくれています。
署名開始から 7～30 日以内に、ゾーンで通常の ZSK ローテーションの実行を開始します。現在、Route 53 は事前公開キーロールオーバー方式を使用しています。詳細については、「Pre-Publish Zone Signing Key Rollover (事前公開ゾーン署名キーのロールオーバー)」を参照してください。この方法では、ゾーンに別の ZSK を導入します。ローテーションは 7～30 日ごとに繰り返されます。
というわけでKSKについては手動でローテーションする必要があるのですが、以前の記事でも紹介しましたとおりDNSSECの設定は対応を誤ると対象のドメインそのものにアクセスができなくなるという非常に影響が大きな内容となっています。繰り返しとなりますが是非以下のSlack社の事例もご参照ください。
KSKのローテション方法には以下の方式があり、今回はAWSブログに記載の「Double-RRset方式」を実際にやってみます。
- Double-Signature方式
- Double-DS方式
- Double-RRset方式
RFC 6781にはローテーション方式として「Double-Signature方式」と「Double-DS方式」は記載されていますが「Double-RRset方式」は明記されていません。「Double-RRset方式」についてはRFC 6781より後に公開されたRFC 7583に記載されています。RFC 7583はDNSSECにおける鍵のロールオーバーのタイミングに関する考慮点に焦点を当てたものとなりますので、各方式の違いについては当該RFCおよび本記事末尾の参考もご参照ください。
やってみた
以前の記事に記載の前提知識については割愛させていただきます。
事前準備
まず、現在の登録状況を確認していきます。対象のドメインでDNSSECが有効化されている場合、Route 53の登録済みドメインでは以下のように表示されます。
上記で登録されている内容を確認するには、以下のように対象のホストゾーンから[DSレコードを作成するための情報を表示]を選択します。
登録情報が表示されるので、[別ドメインレジストラ]のパブリックキー(①)とDSレコード(②)に着目してみます。
digコマンドで対象ドメイン(example.comに置換)を確認すると以下のとおりです。（ハッシュ値部分には適当な文字を混ぜています）
$ dig example.com +trace +multi dnskey
; <<>> DiG 9.10.6 <<>> example.com +trace +multi dnskey
;; global options: +cmd
. 156454 IN NS c.root-servers.net.
. 156454 IN NS b.root-servers.net.
. 156454 IN NS j.root-servers.net.
. 156454 IN NS g.root-servers.net.
. 156454 IN NS h.root-servers.net.
. 156454 IN NS e.root-servers.net.
. 156454 IN NS i.root-servers.net.
. 156454 IN NS l.root-servers.net.
. 156454 IN NS d.root-servers.net.
. 156454 IN NS m.root-servers.net.
. 156454 IN NS f.root-servers.net.
. 156454 IN NS a.root-servers.net.
. 156454 IN NS k.root-servers.net.
;; Received 811 bytes from 2001:a7ff:5f01::a#53(2001:a7ff:5f01::a) in 26 ms
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 86400 IN DS 19718 13 2 (
8ACBB0CD28F41250A80A491389424D341522D946B0DA
0C0291F2D3D771D7805A )
com. 86400 IN RRSIG DS 8 1 86400 (
20250403050000 20250321040000 26470 .
Zk2qfAs8ddXSFS8+lJblOzCI3aqLKDbwaRHWG/RYITPc
jfuKXlcU9RfNMm3O7OzXnF8PSenILG6x89iUsp9Ra2oM
RqC9x/zxLdz3GalWGS4hLglRx6QHh6zDmTLeNUt0zyWN
z6mQKcOIa4OPcnah3LzHEgmAik/FIOij2zCC3bjmwFI0
sypJAgkJfovrKeW1D12nh/cDO2C5lRBaTgeDg2AP35/Y
/cD2O3bLNVBJFoMs3U9Vs07GGO/Rdn3Fv7kPlKQtL+MW
Drokys7bVUpgViHnJGhAnaXAFoKwz2+FNSr5Bc6qfWij
NG1HVGf7wA1FmwQwZgaMfLKj/OM7XoyzvQ== )
;; Received 1171 bytes from 2001:500:a8::e#53(e.root-servers.net) in 22 ms
example.com. 172800 IN NS ns-160.awsdns-20.com.
example.com. 172800 IN NS ns-801.awsdns-36.net.
example.com. 172800 IN NS ns-1911.awsdns-46.co.uk.
example.com. 172800 IN NS ns-1503.awsdns-59.org.
example.com. 86400 IN DS 18409 13 2 (
ZD3B4FCC3EAC69BF8DDAD82A86B6606562FC1F6A91DC
55F7F23A8C9D8FB3E63C )
example.com. 86400 IN RRSIG DS 13 2 86400 (
20250328020807 20250321005807 23202 com.
ZDBeoOBGJERL8HYNS7wUacbEElSail7b9+51bLTnAj6J
wEZElofLzoQr34UvAcIyFYGNl0SwLPHU5emHjBLpug== )
;; Received 340 bytes from 192.43.172.30#53(i.gtld-servers.net) in 122 ms
example.com. 3600 IN DNSKEY 256 3 13 (
ZaqUvMhdqum7MBMpHw/Rc+wyjAJaUMO4tbMVX0hyQSg7
uDyNh9rf8AWUAQXzifrcPa0pyI+MVu6QKY5oF5HhSw==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 60916
example.com. 3600 IN DNSKEY 256 3 13 (
Z/qANG+Kde9rmSeXt+QIb3Z5J/WR187IjyJs8InJfw44
Cu2WAjsTPgMgM+XbRKQft4RQwPwSRjz2JpobZsyPmQ==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 3061
example.com. 3600 IN DNSKEY 257 3 13 (
ZlZhcp7CY385gnJeJJf7LO/7E9aHlpEIlZaQD4ht+XvO
EsUHVFbEFmkKXzE0cBieMzZ9JSdKZVRkvNMkOs2JsA==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 18409
example.com. 3600 IN RRSIG DNSKEY 13 2 3600 (
20250321180000 20250321070000 18409 example.com.
ZrP0fZzXW/1ySQxYyxF9lhyvGC+zIPNvVDZRGv4ns9iH
oubu9uT9rbSMnoPqNmYfJI6XDDb5rUwZmCvujJ9lIQ== )
;; Received 387 bytes from 2600:9000:5307:7700::1#53(ns-1911.awsdns-46.co.uk) in 31 ms
上記のうち、以下のAWSのネームサーバ(ns-1911.awsdns-46.co.uk)が回答したDNSKEYレコードの値が①と同じであることが分かります。
example.com. 3600 IN DNSKEY 257 3 13 (
ZlZhcp7CY385gnJeJJf7LO/7E9aHlpEIlZaQD4ht+XvO
EsUHVFbEFmkKXzE0cBieMzZ9JSdKZVRkvNMkOs2JsA==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 18409
また、以下の以下の親ゾーン(.com)のネームサーバ(i.gtld-servers.net)が回答したDSレコードの値が②と同じであることも分かります。
example.com. 86400 IN DS 18409 13 2 (
ZD3B4FCC3EAC69BF8DDAD82A86B6606562FC1F6A91DC
55F7F23A8C9D8FB3E63C )
特に着目する必要があるのは親ゾーンにあるDSレコードのTTLです。上記のとおり86400秒(=24時間)となっていますので、仮に新DSレコードと新KSKを適用後に即座に旧DSレコードと旧KSKを削除した場合、キャッシュDNSサーバ(フルサービスリゾルバ)には旧DSレコードの情報が残ったままとなりますので、DNSクライアント(スタブリゾルバ)からはDNSSECによる信頼の連鎖が崩れたように見え、結果的に対象ドメインにアクセスできなくなります。（このあたりの具体的な事象とその他の想定外の事象がまとまっているのが冒頭のSlack社の事例です）
このため、DSレコードを追加・削除する際はTTLが切れるまで、一般的にはTTLの2倍以上(2日間)はDNSキャッシュが伝播するまでの待ち時間を確保する必要があります。
新しいKSKの追加
それでは、KSKローテーションのためにまず新しいKSKを追加します。[詳細表示に切り替える]を選択しないと[アクション]が表示されないことにご注意ください。
既存のKSKに使用しているものではなく、新規にカスタマーマネージド型キーを作成します。
問題なく登録できました。なお、KSKは1つのホストゾーンに2つまでしか登録できません。
この時点で先ほどと同じようにdigコマンドで確認すると、子ホストゾーン(example.com)で新しく追加したKSKに相当するDNSKEYレコードとRRSIGレコードが追加されていました。各レコードの突き合わせにはDNSKEYレコードのkey idとRRSIGレコードの該当箇所(key tag部分)に着目くだささい。また、既存RRSIGレコードの値も変更されているようです。
$ dig example.com +trace +multi dnskey
（略）
example.com. 3600 IN DNSKEY 256 3 13 (
ZaqUvMhdqum7MBMpHw/Rc+wyjAJaUMO4tbMVX0hyQSg7
DyNh9rf8AWUAQXzifrcPa0pyI+MVu6QKY5oF5HhSw==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 60916
example.com. 3600 IN DNSKEY 256 3 13 (
Z/qANG+Kde9rmSeXt+QIb3Z5J/WR187IjyJs8InJfw44
Cu2WAjsTPgMgM+XbRKQft4RQwPwSRjz2JpobZsyPmQ==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 3061
+example.com. 3600 IN DNSKEY 257 3 13 (
+ ZS6c6e2mQHmM8ucHGQYmJPTuik3BJTPTWmMGeiF/Xku4
+ ++tT6X5YFnoihceDifmzIhWhmhIevPGwsTKpJd7b4A==
+ ) ; KSK; alg = ECDSAP256SHA256 ; key id = 38702
example.com. 3600 IN DNSKEY 257 3 13 (
ZlZhcp7CY385gnJeJJf7LO/7E9aHlpEIlZaQD4ht+XvO
EsUHVFbEFmkKXzE0cBieMzZ9JSdKZVRkvNMkOs2JsA==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 18409
example.com. 3600 IN RRSIG DNSKEY 13 2 3600 (
20250321180000 20250321070000 18409 example.com.
Zo1+bU8ODS1vCTQNBAwDMdAPWB74n4XyJBY6xoBeFR7o
6GdNW5Z+ZEWEwlPLJy8V5h0G5ezHGE/9+MAGjf2ang== )
+example.com. 3600 IN RRSIG DNSKEY 13 2 3600 (
+ 20250321180000 20250321070000 38702 example.com.
+ ZS2CBx6hsctEin7M89JqWeFz4zCyNtj/CX3YTT9Gx4bY
+ emSc3g0ipE8gQksY0aT3FuPsnKtKRJG2l4tyMncoww== )
;; Received 574 bytes from 2600:9000:5303:2100::1#53(ns-801.awsdns-36.net) in 72 ms
新しいDSレコードの追加
作成したKSKの詳細を表示し、親ゾーンに登録するパブリックキーを確認します。今回はRoute 53で登録済みのドメインが対象なので、確認箇所は[Route 53レジストラ]を開いてパブリックキーをコピーします。
コピーした文字列を以下のように登録済みドメインのDNSSEC設定画面から追加します。
追加ボタンを押すと、即時追加ではなく追加リクエストが行われ、完了するとEメールが届くようです。
リクエスト状況を確認するとすぐにステータスは[成功]になっていました。なお、数日経過してもなぜかメールは届きませんでした。（DNSSECを有効化した時のメールは見つかりましたので、振り分け設定とかの問題ではないはず、、）
もう一度digコマンドを実行したところ、結果は以下のとおりです。親ゾーンにDSレコードが追加されて2つになっています。
$ dig example.com +trace +multi dnskey
（略）
example.com. 172800 IN NS ns-160.awsdns-20.com.
example.com. 172800 IN NS ns-801.awsdns-36.net.
example.com. 172800 IN NS ns-1911.awsdns-46.co.uk.
example.com. 172800 IN NS ns-1503.awsdns-59.org.
+example.com. 86400 IN DS 38702 13 2 (
+ Z8C292896D8D8478C2FC1B9C2C90F8FD6FDD7925F1E2
+ 2F0BCE44629FB1D6E93B )
example.com. 86400 IN DS 18409 13 2 (
ZD3B4FCC3EAC69BF8DDAD82A86B6606562FC1F6A91DC
55F7F23A8C9D8FB3E63C )
example.com. 86400 IN RRSIG DS 13 2 86400 (
20250328114554 20250321103554 23202 com.
ZND1/W7yPbt2/UOL/YtCZfdQ5xJnFN1LJkGv6guczKhO
RsgqOx2/GGtDfr/CwN9k5F1Wn32ryB0Vix7lMrzfNA== )
;; Received 388 bytes from 2001:502:7094::30#53(j.gtld-servers.net) in 124 ms
example.com. 3600 IN DNSKEY 256 3 13 (
ZaqUvMhdqum7MBMpHw/Rc+wyjAJaUMO4tbMVX0hyQSg7
uDyNh9rf8AWUAQXzifrcPa0pyI+MVu6QKY5oF5HhSw==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 60916
example.com. 3600 IN DNSKEY 256 3 13 (
Z/qANG+Kde9rmSeXt+QIb3Z5J/WR187IjyJs8InJfw44
Cu2WAjsTPgMgM+XbRKQft4RQwPwSRjz2JpobZsyPmQ==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 3061
example.com. 3600 IN DNSKEY 257 3 13 (
ZS6c6e2mQHmM8ucHGQYmJPTuik3BJTPTWmMGeiF/Xku4
++tT6X5YFnoihceDifmzIhWhmhIevPGwsTKpJd7b4A==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 38702
example.com. 3600 IN DNSKEY 257 3 13 (
ZlZhcp7CY385gnJeJJf7LO/7E9aHlpEIlZaQD4ht+XvO
EsUHVFbEFmkKXzE0cBieMzZ9JSdKZVRkvNMkOs2JsA==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 18409
example.com. 3600 IN RRSIG DNSKEY 13 2 3600 (
20250321180000 20250321070000 18409 example.com.
Zo1+bU8ODS1vCTQNBAwDMdAPWB74n4XyJBY6xoBeFR7o
6GdNW5Z+ZEWEwlPLJy8V5h0G5ezHGE/9+MAGjf2ang== )
example.com. 3600 IN RRSIG DNSKEY 13 2 3600 (
20250321180000 20250321070000 38702 example.com.
ZS2CBx6hsctEin7M89JqWeFz4zCyNtj/CX3YTT9Gx4bY
emSc3g0ipE8gQksY0aT3FuPsnKtKRJG2l4tyMncoww== )
;; Received 574 bytes from 2600:9000:5307:7700::1#53(ns-1911.awsdns-46.co.uk) in 167 ms
上記のとおり現状は新旧のDSレコードとKSKが存在する状態に見えますが、これはdigコマンドで「+trace」オプションを有効にしている(= 名前解決にキャッシュDNSサーバを使用していない)ためです。キャッシュDNSサーバにキャッシュが存在している場合、レコード情報は古いままの可能性が高いため、前述のとおりこの後はキャッシュの伝播を待つ必要があります。
新しいレコードが伝播されるまで待機（2日間またはTTLに応じて）
待ちます。仮にローカル端末から対象ドメインに正常にアクセスできていて、かつキャッシュDNSサーバには既に新しいレコードが伝播されているように見えていても、その他の端末およびその端末が使用するキャッシュDNSサーバでは新しいレコードが伝播されていない可能性がありますので、待ちます。
古いDSレコードとKSKの削除
まず古いDSレコードを削除します。どちらが古いDSレコードなのか分からなくなった場合はキータグから判断します。
こちらも同様にリクエストを実行する形になるようなので結果を表示したところ、すぐにステータスは[成功]になっていました。
続いて古いKSKを非アクティブ化します。
すぐに非アクティブ化されたためそのままKSKを削除します。なお、本番環境であれば旧DSレコードを削除および旧KSKを非アクティブ化した時点で、KSKを削除する前に念のため再度期間を置き、本当にサービス影響が無いことを確認した上で削除する方がより確実かもしれません。
再度digコマンドを実行した結果は以下のとおりです。古いDSレコードとKSKが無くなり、新しいDSレコードとKSKだけになりました。なお、これまでの間で対象ドメインへのアクセス可否は都度確認していましたが、特にアクセスできなくなることはありませんでした。ただし、ローカル端末からの確認だけですので、サービス影響の大きい本番環境であれば、理想としては前述のSlack社の事例にあるようにサービス稼働状況を何らかのツールでモニタリングできるようにしておく方が良いかと思います。
$ dig example.com +trace +multi dnskey
（略）
example.com. 172800 IN NS ns-160.awsdns-20.com.
example.com. 172800 IN NS ns-801.awsdns-36.net.
example.com. 172800 IN NS ns-1911.awsdns-46.co.uk.
example.com. 172800 IN NS ns-1503.awsdns-59.org.
example.com. 86400 IN DS 38702 13 2 (
Z8C292896D8D8478C2FC1B9C2C90F8FD6FDD7925F1E2
2F0BCE44629FB1D6E93B )
example.com. 86400 IN RRSIG DS 13 2 86400 (
20250328124428 20250321113428 23202 com.
ZNCdNxh6OrgXcZnyGsb2KF9msiyqtvLxmt4Cmd0G6LBH
qHf28bEd9BzpVFqAEiVreC7LhJkzeEeUzUsDv6Vw7w== )
;; Received 340 bytes from 2001:502:1ca1::30#53(e.gtld-servers.net) in 46 ms
example.com. 3600 IN DNSKEY 256 3 13 (
ZaqUvMhdqum7MBMpHw/Rc+wyjAJaUMO4tbMVX0hyQSg7
uDyNh9rf8AWUAQXzifrcPa0pyI+MVu6QKY5oF5HhSw==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 60916
example.com. 3600 IN DNSKEY 256 3 13 (
Z/qANG+Kde9rmSeXt+QIb3Z5J/WR187IjyJs8InJfw44
Cu2WAjsTPgMgM+XbRKQft4RQwPwSRjz2JpobZsyPmQ==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 3061
example.com. 3600 IN DNSKEY 257 3 13 (
ZS6c6e2mQHmM8ucHGQYmJPTuik3BJTPTWmMGeiF/Xku4
++tT6X5YFnoihceDifmzIhWhmhIevPGwsTKpJd7b4A==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 38702
example.com. 3600 IN RRSIG DNSKEY 13 2 3600 (
20250321180000 20250321070000 38702 example.com.
ZbHSP4yzbABfiE1bw3jX7cBAUYmN8HrrohvjQ8URaf3N
AplCTq6/FbtBj9g3RP0hyA75Mn3MmPwz6VGBVjSOSQ== )
KSKはすぐに削除されましたがKMSのカスタマーマネージド型キーは残ったままですので、課金が発生しないためにも削除します。対象のキーが存在するリージョンはus-east-1です。
なお、即時削除はできず、少なくとも7日間はかかることにご注意ください。
まとめ
レコードの伝播を待ったりサービス影響を気にしたりと注意点はあるものの、Route 53で登録済みのドメインであれば親ゾーンの設定を含めてマネジメントコンソール上で設定作業を完結できることは良いなと思いました。
本記事がどなたかのお役に立てれば幸いです。
