新しいメールサーバの準備から、データをコピーしてDNSレコードを変更するまでのメールサーバ移行に必要な手順のまとめです。
新しいメールサーバの準備
既存メールサーバとできるだけ同じ構成にします。 レンタルサーバのメールには独自機能(同一ユーザーで複数ドメインのメールアドレスを使うなど)が実装されていることがあります。 新しいメールサーバで既存サーバと同じ設定ができるか確認します。 難しい場合には運用を変えることを検討します。
アカウント作成
既存メールサーバと同じアカウント情報で新しいメールサーバにアカウントを作成します。
接続確認
普段使っているメールソフトから新しいメールサーバへ接続確認を行います。 メールサーバによってポート番号や認証方法が異なることがあります。 新しいメールサーバを用意したら必ず確認します。 メールソフトの設定を変更する必要があればメモします。 他にも利用者がいればあらかじめ変更内容を伝えておきます。
SSL証明書
SSLを利用する場合は証明書が正しく設定できているか確認します。 SSL検証のためホスト名で接続する必要があります。 一時的にhostsファイル 1 を書き換えます。 メールソフトから新しいメールサーバに接続し不具合がないことを確認します。
データのコピー
既存サーバから新しいサーバにデータをコピーします。データをコピーする時は「ラベル」や「フォルダ」等の
メタデータ
が失われないように気をつけます。 メールソフト(Mail.app/Thunderbird/Becky!)を使う方法
2
と
imapsync
3
を使う方法があります。
DNSレコード変更
メールサーバのホスト名を新しいIPアドレスに結びつけます。 メールアドレスのドメインを管理しているネームサーバのDNSレコードを変更します。 IPの指定を誤ると自分宛に送信されたメールが最悪の場合破棄されますので絶対に避けなければなりません。
DNSの浸透問題
DNSはキャッシュの仕組みがあるため変更が反映されるまでに時間がかかります。 いつ反映されるのかがわかりづらく「DNSの浸透 4 」と表現されることがあります。 反映に時間がかかると古いサーバに多くのメール届き後から調整するのが大変になります。 うまく準備を行えば事前に計画した時間通りにDNS情報を反映できます。
TTL
DNSレコードの変更が反映されるまでの時間はAレコードのTTLで制御できます。TTLを超えて古いデータ(キャッシュ)が使われることはありません。
REFRESH
セカンダリ(スレーブ)ネームサーバを使っている場合はゾーン情報の更新時間にも気をつける必要があります。 プライマリネームサーバのDNSレコードを変更してからセカンダリネームサーバが最新の情報を取得(ゾーン転送)するまでには時間がかかります。 この、ゾーンの情報をリフレッシュするまでの時間はSOAレコード
5
の
REFRESH
というパラメータに設定されています。
手順
-
Aレコードの
TTL
を短くする。- 当初設定が1日だとすると1時間に変更する。
-
SOAレコードの
REFRESH
を短くする。 -
次の内から一番長いものの時間以上待つ。
-
Aレコードの当初設定
TTL
-
SOAレコードの当初設定
REFRESH
-
Aレコードの当初設定
- AレコードのIPを変更する。
-
TTL
とREFRESH
に設定した時間以上待つ。
- 変更が反映されているかいくつかのネームサーバで確認する。変更が反映されていない場合は原因を究明する。
-
Aレコードの
TTL
、SOAレコードのREFRESH
を元に戻す。
この方法を取ればAレコード変更の反映を素早く行うことができます。 反映までの時間は最大で
TTL
と
REFRESH
を足した時間になります。
切り替えのタイミング
メールサーバへのアクセスが少ない時間帯に切り替えを行います。 誰かが自分宛にメールを送信する可能性がある時間帯は避けます。 また切り替え前後はメールソフトでメールの確認や送信を行わないようにします。
取りこぼしの確認
DNS反映にはタイムラグがありますのでメールの取りこぼし(古いサーバにメールが届く)を完全に無くすことはできません。
TTL
に従わないDNSキャッシュサーバ
6
が一定数存在していると言われます。 また
REFRESH
はあくまで更新タイミングの目安であり時間内のゾーン転送が保証されているわけではありません。
1通のメールの取りこぼしが大きな機会損失に繋がることもあります。DNS反映が完了した後も定期的に古いサーバにメールが届いていないか確認します。