変更前に保存する情報
A・AAAA・CNAME、MX、TXT、NS、TTL、DNSSECなどを確認します。Webの移行でネームサーバーを変える場合は、メール認証やサービス所有確認のTXTが抜けないか照合します。ドメインの契約者、期限、2FAも点検します。
TTLだけで完了時刻を保証しない
既存キャッシュ、委任、利用者側のリゾルバーなどで反映に差が出ます。TTLは確認の材料ですが、設定値だけで全利用者の切替時刻を保証できません。新旧環境が混在する間の書込み先を計画します。
変更を進める順序
新サーバーと証明書を用意し、公開切替前に検証します。URLが変わるならDB内の参照とリダイレクトを調整します。変更後は複数の経路で名前解決、HTTPS、フォーム、メール、検索向け設定を確認します。
差戻しを準備する
旧環境をすぐ削除せず、DNSを戻す条件とデータ差分を決めます。新環境で受けた注文や登録を無視して戻すと損失が出ます。完了判断はWeb表示だけでなく関係サービスの正常性も含めます。
変更計画を作る例
現在の全レコードをエクスポートまたは記録し、変更する行と維持する行を区別します。Webだけ移すなら、メールや所有確認のレコードを変更する必要があるかを慎重に判断します。DNSSECやネームサーバーの委任を変える場合は、レジストラとDNS提供者の手順を合わせます。
切替中の業務データ
新旧の配信が混ざる時間に、旧環境へ注文や申込みが入る可能性があります。書込み停止、最終同期、旧環境の監視、データ回収を計画し、旧環境をすぐ消さないようにします。
よくある質問
TTLが600なら10分で全て切り替わりますか？
全利用者の完了を保証する値ではありません。既存キャッシュや委任などの条件があり、複数経路の確認と移行期間の計画が必要です。
サイトが開けばDNS変更は完了ですか？
メール、HTTPS、www有無、外部連携、検索向け設定も確認します。Web表示以外の関係サービスも完了条件に含めます。