サーバー移転のDNS切り替え手順とTTLの考え方

サーバー移転のトラブルは DNS の切り替えに集中します。TTL を事前に短くする理由と時期、当日の作業の順序、SSL 証明書の用意、ネームサーバー変更で MX や SPF を失ってメールを止めないための手順を説明します。

切り替えで起きる問題

サーバー移転で起きるトラブルは、ファイルの移動そのものより、DNS の切り替えに集中します。切り替えの直後には「人によって新旧どちらのサーバーに行くか分からない」時間が必ず生まれ、その間にフォームからの問い合わせが旧サーバーに届いて消える、新サーバーの証明書が間に合わず警告が出る、メールが止まる、といった問題が起きます。

DNS の変更は、設定した瞬間に世界中へ届くわけではありません。各レコードには TTL(秒)が設定されており、閲覧者のプロバイダーや社内のキャッシュ DNS は、その秒数の間は古い値を返し続けます。TTL が 86400(1日)なら、変更から最大1日は旧サーバーに向く人が残ります。

TTL を事前に短くする

この待ち時間は、切り替えの前に TTL を短くしておくことで、数分に縮められます。

移転の2〜3日前に、変更する A レコード(と、あれば AAAA レコード)の TTL を 300(5分)程度に下げます。このとき注意すべきなのは、TTL の短縮そのものが、元の TTL の時間が経つまで世界に行き渡らないことです。元が 86400 なら、下げてから1日待って初めて「5分で切り替わる」状態になります。前日ではなく、余裕を持って下げてください。

切り替えが終わって数日経ったら、TTL を 3600 以上に戻します。短いままだと DNS への問い合わせが増えて権威サーバーの負荷が上がり、権威サーバーに障害が起きたときに影響が出るまでの猶予も短くなります。

切り替え当日の順序

当日の作業は、新サーバーがいつでも本番として動ける状態を先に作り、最後に DNS を変えます。

まず新サーバーにファイルとデータベースを移し、自分のパソコンの hosts ファイルで新サーバーの IP を指定して、DNS を変えずに新サーバーの表示を確かめます。次に新サーバーで SSL 証明書を用意します。Let's Encrypt の HTTP-01 認証は DNS が新サーバーを向いていないと通らないため、事業者の管理画面に事前発行の仕組みがなければ、DNS-01 認証を使うか、切り替え直後に取得します。切り替え直後の数分間だけ警告が出る場合は、作業時間を深夜にするなどで影響を抑えます。

DNS を変更したら、DNSレコード確認で A レコードが新しい IP を返すかを確かめ、SSL証明書チェックで新サーバーの証明書が返っているかを見ます。旧サーバーは最低でも元の TTL の時間、できれば1週間は止めず、旧サーバー側のアクセスログが減っていくのを確かめてから解約します。

メールを止めないために

Web だけを移転し、メールは今までのサーバーに残す場合は、A レコードだけを変え、MX レコードは触りません。ところが、ネームサーバーごと新しい事業者に変えると、新しいゾーンには旧サーバーの MX や SPF が引き継がれないため、メールが届かなくなります。ネームサーバーを変える前に、現在のゾーンの全レコード(MX、TXT の SPF と DKIM と DMARC、サブドメインの CNAME)をDNSレコード確認で控え、新しいゾーンに同じ値を先に登録してください。

メールも一緒に移転する場合は、SPF の include: を新しいメールサーバーのものに変え、DKIM の公開鍵も新しいものに置き換えます。SPF が旧サーバーのままだと、新サーバーから送ったメールが Gmail などで迷惑メール扱いになります。詳しくはSPF・DKIM・DMARC の設定にまとめています。

確認に使えるツール

• DNSレコード確認: A、MX、TXT、NS の現在の値と TTL を確認します
• SSL証明書チェック: 新サーバーの証明書が返っているかを確認します