Route 53で管理しているドメインでDNSSECを無効化する
2025.03.25こんにちは、なおにしです。
Route 53で管理しているドメインで設定済みのDNSSECを無効化する機会がありましたのでご紹介します。
はじめに
今回は以下の記事で有効化したDNSSECを無効化します。
Route 53でDNSSECを有効化したものの、KSKのローテーションが手間(※1)だったりKMSのカスタマーマネージド型キーの料金を抑えたかったり(※2)という運用面の理由でDNSSECを無効化したくなることがあるかもしれません。
より大きな理由としては、ドメイン移管が必要になった状況でDNSSECを無効化しなければいけないというパターンの方があり得るかと思います。
-
(※1) KSKのローテーション(ロールオーバー)はベストプラクティスとして推奨されているものであって、必須ではありません。
- 具体的なローテーション手順についてはこちらの記事もご参照ください。
-
(※2) 通常であれば1ホストゾーンに1つのKSKのみになるので、カスタマーマネージド型キーも1つであれば1ドル/月です。
前述の記事で何度も記載していますが、DNSSECの設定は対応を誤ると対象のドメインそのものにアクセスができなくなるので、設定後の待ち時間やサービス継続性のモニタリングなど考慮が必要です。
AWSのドキュメントでは以下のページが今回の主旨に沿ったタイトルになっていますが、内容としては親ゾーンの管理がRoute 53以外の別レジストラであることも考慮した汎用的なものになっています。
このため、こちらのドキュメントおよびAWSブログの内容も踏まえて、Route 53で登録済みのドメインで有効化していたDNSSECを無効化してみます。
やってみた
事前準備
DNSSEC無効化前の状態は以下のとおりです。対象ドメイン(example.com)のDNSKEYレコードに対応するDSレコードが親ゾーンに存在しています。
$ dig example.com +trace +multi dnskey
; <<>> DiG 9.10.6 <<>> example.com +trace +multi dnskey
;; global options: +cmd
. 323120 IN NS k.root-servers.net.
. 323120 IN NS l.root-servers.net.
. 323120 IN NS i.root-servers.net.
. 323120 IN NS e.root-servers.net.
. 323120 IN NS a.root-servers.net.
. 323120 IN NS h.root-servers.net.
. 323120 IN NS f.root-servers.net.
. 323120 IN NS b.root-servers.net.
. 323120 IN NS m.root-servers.net.
. 323120 IN NS j.root-servers.net.
. 323120 IN NS g.root-servers.net.
. 323120 IN NS d.root-servers.net.
. 323120 IN NS c.root-servers.net.
;; Received 811 bytes from 2001:a7ff:5f01::a#53(2001:a7ff:5f01::a) in 50 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.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 (
ZACBB0CD28F41250A80A491389424D341522D946B0DA
0C0291F2D3D771D7805A )
com. 86400 IN RRSIG DS 8 1 86400 (
20250406050000 20250324040000 26470 .
ZU1HLMtiE9LdH0nQ2Cm+ViCXN9WJgnXM/B8rpqlaEiNE
W5YXGqfK6rmpLsRKk6lRUtwXZSPE6tjYHAnyFngrwe8o
Il4/WER9CBEB48lZzweuzNuIXrM/Z+dPiBB+bcD4zIkY
313Zhw+7QFfEUfU5rp5ECZ97TBpF5z2ObEdi6Kxni8Ce
P9UWQ4RVbCSBXahPqPLWEZBQk+4Dxd/znbzTCq5K8chr
7kN3irptVZg45Vv5NBJSxZJ7O4K5w33jg32j3yTLwRZT
wKdLVl/MqskZLBLlaDgHV4M4/rlYYlDNkCMCiFuQYhFA
yqZ1bcdS5Wm0bC40n4HumjJ2iTAQ5vC8Kw== )
;; Received 1171 bytes from 2001:7fd::1#53(k.root-servers.net) in 28 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 38702 13 2 (
Z8C292896D8D8478C2FC1B9C2C90F8FD6FDD7925F1E2
2F0BCE44629FB1D6E93B )
example.com. 86400 IN RRSIG DS 13 2 86400 (
20250328124428 20250321113428 23202 com.
ZNCdNxh6OrgXcZnyGsb2KF9msiyqtvLxmt4Cmd0G6LBH
qHf28bEd9BzpVFqAEiVreC7LhJkzeEeUzUsDv6Vw7w== )
;; Received 340 bytes from 192.33.14.30#53(b.gtld-servers.net) in 234 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 (
20250324180000 20250324070000 38702 example.com.
Z4oVKDYwK8AGaH92QDvY3zU+wV6L5j/NzPsrdtf7gmbD
0UWhbfZ2aGyTLlWbF1ZBc/UJUsQXCUiryGck9ogkgA== )
;; Received 387 bytes from 205.251.197.223#53(ns-1503.awsdns-59.org) in 33 ms
Google Public DNS(8.8.8.8)に対してDSレコードを問い合わせた結果は以下のとおりです。
$ dig example.com @8.8.8.8 +multi ds
; <<>> DiG 9.10.6 <<>> example.com @8.8.8.8 +multi ds
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21220
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com. IN DS
;; ANSWER SECTION:
example.com. 21600 IN DS 38702 13 2 (
Z8C292896D8D8478C2FC1B9C2C90F8FD6FDD7925F1E2
2F0BCE44629FB1D6E93B )
;; Query time: 32 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Mar 24 18:13:03 JST 2025
;; MSG SIZE rcvd: 88
DSレコードの削除
前述のドキュメントに記載の「ドメインのパブリックキーの削除」のとおり設定します。なお、ドメインのパブリックキーとなっていますが、実際に削除されるのはDSレコードです。
削除リクエストが実行されました。
リクエストはすぐに[成功]ステータスになりました。
この時点でのdigの結果は以下のとおりです。親ゾーンからDSレコードが削除され、不在証明のNSEC3レコードおよびそれに対応するRRSIGレコードが追加されました。
$ 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.
+CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - (
+ ZK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL
+ NS SOA RRSIG DNSKEY NSEC3PARAM )
+CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 (
+ 20250328002636 20250320231636 23202 com.
+ ZBU62q/UgrFdNVVW6A8S85lT6u67WIgo3xDumaNtDdNQ
+ cLR6/8TqCL5pA4qqxFquM/ysKrcz0LFlcYfKB1cvBw== )
+7B64LEOFMHJJDN47IQ710Q3JJV6BUUDE.com. 900 IN NSEC3 1 1 0 - (
+ ZB65EVDGGKHBAVN3N2PUNLS54ORVC1IV
+ NS DS RRSIG )
+7B64LEOFMHJJDN47IQ710Q3JJV6BUUDE.com. 900 IN RRSIG NSEC3 13 2 900 (
+ 20250331091634 20250324080634 23202 com.
+ ZpR2f6PvixyaD5FFcX4KlDZsy2hcwageb0dGydkUd46s
+ x1kx76vRdRUtbW3nJ6zDcCXcfxp2hbAJHuzOgIWPMg== )
;; Received 550 bytes from 2001:503:eea3::30#53(g.gtld-servers.net) in 125 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 (
20250324180000 20250324070000 38702 example.com.
Z4oVKDYwK8AGaH92QDvY3zU+wV6L5j/NzPsrdtf7gmbD
0UWhbfZ2aGyTLlWbF1ZBc/UJUsQXCUiryGck9ogkgA== )
;; Received 387 bytes from 205.251.199.119#53(ns-1911.awsdns-46.co.uk) in 32 ms
同じタイミングでGoogle Public DNS(8.8.8.8)に対して再度DSレコードを問い合わせたところ、こちらは想定していた挙動に反して、DSレコードが存在しないためSOAレコードが返ってきています。キャッシュされたDSレコードが返ってくるかと思いましたが、Google Public DNSという非常に有名なサービスなのでDNSSEC周りは個別の実装がなされているのかもしれません。
$ dig example.com @8.8.8.8 +multi ds
; <<>> DiG 9.10.6 <<>> example.com @8.8.8.8 +multi ds
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60487
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com. IN DS
;; AUTHORITY SECTION:
+com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. (
+ 1742807917 ; serial
+ 1800 ; refresh (30 minutes)
+ 900 ; retry (15 minutes)
+ 604800 ; expire (1 week)
+ 900 ; minimum (15 minutes)
+ )
;; Query time: 134 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Mar 24 18:19:00 JST 2025
;; MSG SIZE rcvd: 113
ちなみにwhoisで調べた結果もこの時点でunsignedになっていました。DNSSECが正しく設定されている場合はsignedDelegationと表示されます。
$ whois example.com | grep -i dnssec
DNSSEC: unsigned
DNSSEC: unsigned
DNSSEC: unsigned
この時点では、仮にDSレコードがキャッシュとして残っているキャッシュDNSサーバを利用していたとしても、対応するKSKがまだ削除されていないため、DSレコードが存在しなくなったことによる影響はありません。
DSレコードの削除が伝播されるまで待機（2日間またはTTLに応じて）
待ちます。Google Public DNSではDSレコードの削除をすぐに認識できたようですが、全てのキャッシュDNSサーバが同様の挙動になるとは限りません。ドキュメントには以下の記載もあります。
- DNSSEC を無効にする場合、まずドメインのパブリックキーを削除します。ドメインの DNS サービスで DNSSEC を無効にする前に、最大 3 日待つことをお勧めします。
DNSSEC署名の無効化
DSレコードが削除されたためDNSSECとしては設定されていない状態になりましたが、ホストゾーンの設定では以下のようになったままなので[DNSSEC署名を無効化します]を選択します。
無効化のポップアップには改めて注意事項が記載されています。今回は親ゾーンに現在のゾーンのDSレコードがあるパターンでした。ここまでの作業でステップ3までが完了している状態なので無効化します。
今回の設定は親ゾーンとは関係ないものなのでリクエスト扱いにはならず、すぐに無効化状態になりました。
ただし、KSKについてはアクティブ状態で残っていますので、非アクティブ化した上で削除します。ちなみに非アクティブ化しなくても削除が選択できるようだったので試しに操作してみましたがエラーが発生しました。
削除画面にもDSレコードを先に削除しないと信頼の連鎖が壊れる旨の警告が表示されています。
最終的なdigの結果は以下のとおりです。DNSSEC署名の無効化に伴ってDNSKEYレコードも削除されたため、SOAレコードが応答として返ってくるようになりました。
$ 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.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - (
ZK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL
NS SOA RRSIG DNSKEY NSEC3PARAM )
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 (
20250328002636 20250320231636 23202 com.
ZBU62q/UgrFdNVVW6A8S85lT6u67WIgo3xDumaNtDdNQ
cLR6/8TqCL5pA4qqxFquM/ysKrcz0LFlcYfKB1cvBw== )
7B64LEOFMHJJDN47IQ710Q3JJV6BUUDE.com. 900 IN NSEC3 1 1 0 - (
ZB65EVDGGKHBAVN3N2PUNLS54ORVC1IV
NS DS RRSIG )
7B64LEOFMHJJDN47IQ710Q3JJV6BUUDE.com. 900 IN RRSIG NSEC3 13 2 900 (
20250331091634 20250324080634 23202 com.
ZpR2f6PvixyaD5FFcX4KlDZsy2hcwageb0dGydkUd46s
x1kx76vRdRUtbW3nJ6zDcCXcfxp2hbAJHuzOgIWPMg== )
;; Received 550 bytes from 192.43.172.30#53(i.gtld-servers.net) in 237 ms
+example.com. 900 IN SOA ns-801.awsdns-36.net. awsdns-hostmaster.amazon.com. (
+ 1 ; serial
+ 7200 ; refresh (2 hours)
+ 900 ; retry (15 minutes)
+ 1209600 ; expire (2 weeks)
+ 86400 ; minimum (1 day)
+ )
;; Received 121 bytes from 2600:9000:5303:2100::1#53(ns-801.awsdns-36.net) in 72 ms
KMS カスタマーマネージド型キーの削除
KSKは削除されましたがKMSのカスタマーマネージド型キーは残ったままですので、課金が発生しないためにも削除します。対象のキーが存在するリージョンはus-east-1です。
なお、即時削除はできず、少なくとも7日間はかかることにご注意ください。
補足
試しにDSレコードが存在する状態でKSKを削除するというアンチパターンの操作ができるかやってみました。DNSSECによる信頼の連鎖が構成されている状態で対象ドメインのKSKを削除してしまった場合、想定される挙動としては信頼の連鎖が崩れてドメインにアクセスできなくなるかと思います。まず対象のKSKを非アクティブ化します。
エラーが出力されて削除以前に非アクティブが失敗しました。先に親ゾーンのDSレコードを削除するように促されますので、こちらのアンチパターンは操作としてできなくなっているようです。
まとめ
キー署名キー(KSK)のローテーション作業と同様に、DSレコードの削除といったドメインレジストラとして対応が必要な操作もRoute 53のマネジメントコンソール画面から可能なので便利だと思いました。
ドキュメントには以下の記載もありますので、無効化作業が終わったらすぐに完了というわけではなく、一部の利用者でドメインにアクセスができなくなっているなどの問題が発生していないか、一定期間注視する必要があります。
リゾルバーがゾーンを検証する問題がないことを確認する必要があります。顧客が問題を報告するために必要な時間も 1～2 週間ぐらい考慮してください。
本記事がどなたかのお役に立てれば幸いです。
