メインコンテンツへ移動
Boletolibre

イベント用ドメインのDNSSEC移行チェックリスト

新しいDNSレコードが正しくても、親ゾーンのDSが署名鍵と合わなければDNSSEC検証で失敗します。本シートはそれを普遍的な操作手順にせず、関係者の判断と証拠を整理します。

Boletolibre編集部

公開日

登録側DS、旧新DNS事業者の鍵、イベントサービスの検証を示す図。
対応機能を確認してから移行方式を決めます。

DNSサービス移行と登録移管を区別する

オリジナルのDNSSEC引き継ぎシートをダウンロード(Markdown、英語)

ドメイン、登録事業者、旧新DNS事業者、影響するWeb、申込、チケット、メールを記録します。DNSSECの有効状態と親ゾーンのDSを確認します。DS変更の権限者と署名鍵の管理者は別の場合があります。[1][2]

事業者が正式に対応する方式を選ぶ

Google Cloudは両事業者と登録側が必要な機能に対応するときの信頼チェーン維持方式を説明します。Cloudflareには複数署名者の方式があります。一方、Route 53のホストゾーン移行はDNSSEC設定をそのまま移せないと記載しています。異なる手順を混ぜず、実際の資料と専門担当者の承認を残します。[1][3][2]

一時的なDNSSEC停止を明示する

方式によっては親側で一時的にDNSSECを無効にします。Googleはその間の保護低下と、DNSSECに依存する機能への影響を警告しています。DANE/TLSAなどの依存があれば専門家に確認し、無停止を約束しません。[1][2]

信頼チェーンと参加者の操作を検証する

旧新ゾーンの内容、権威サーバーのDS・DNSKEY、検証するリゾルバーの結果を記録します。Web、申込、チケット、メールも確認します。待機条件は実際のキャッシュ時間と採用した事業者の資料に基づけます。旧事業者の停止時期と復旧判断者も明確にします。[1][3]

出典と参考資料

  1. Migrate or transfer DNSSEC-enabled zonesGoogle Cloud Documentation · 確認日
  2. Migrating a hosted zone to a different AWS accountAmazon Route 53 · 確認日
  3. DNSSEC migration tutorialCloudflare DNS documentation · 確認日
  4. Enabling DNSSEC signing and establishing a chain of trustAmazon Route 53 · 確認日