ホームページ移転でDNSを切り替える前にwebとmailの向き先を分けて確認する

ホームページを別のserverへ移すとき、DNSの切替はwebサイトだけの作業ではありません。同じdomain nameは、web siteの行き先だけでなく、mailやほかのサービスを調べる手掛かりにも使われます。新しいホームページが表示できることだけを確認して切り替えると、mailが届かない、wwwを付けたURLだけが古い場所へ行く、といった問題を見落とします。切替前に、何をどこへ向けているかを分けて控えます。

DNSは、domain nameと、その名前に結び付く情報を扱う仕組みです。Internetでは、host address、mailboxに関するdataなど、目的の異なる情報を名前から取り出します。したがって、web siteの移転とmailの運用を、同じdomainを使っているから一つの変更として片付けてはいけません。新しいserverへwebを向ける仕事と、今のmailの受け方を残す仕事を分けます。

最初にするのは、管理画面で設定を書き換えることではありません。今のdomain nameで、root domain、wwwを付けたname、mailの送受信に関係する設定が、誰の管理で、どこを向いているかを一枚の表にします。画面を見ながら覚えて変更すると、元へ戻すための情報まで失います。

domainを使う仕事を一つずつ書き出す

移転の対象を「ホームページ」とだけ書くと、範囲があいまいになります。読者がbrowserへ入力するURL、広告や名刺に印刷したURL、wwwを付けたURL、問い合わせformから送るmail、社員が使うmail addressは、同じ名前を含んでいても確認する相手が違うことがあります。

説明用の仮例として、example.jpを使う会社を考えます。browserでexample.jpを開く人と、www.example.jpを開く人の両方を新しいsiteへ案内したいとします。一方で、info@example.jpは以前から使っており、mail serviceは移転しないとします。この場合、web siteを新serverへ向けるための変更と、mailを今までどおり受け取るための設定は、同じ目的ではありません。

表には、少なくとも次の項目を残します。

1. 外部へ案内しているdomain nameとURL。
2. root domainとwwwを付けたnameを、どちらも利用者が開けるようにするか。
3. mail address、問い合わせformの送信先、送信に使うaddress。
4. domainの契約先、DNSを変更できるaccount、serverの管理者。
5. 変更前の設定内容、控えを取った日、切替後に確かめる担当。

この表の目的は、専門用語を並べることではありません。何を変えると誰が困るかを、変更前に見えるようにすることです。制作会社がserverを用意しても、domainのaccountやmailの設定まで自動で引き継ぐわけではありません。作業を頼む相手と、domainを管理する人を分けて確認します。

webの表示とmailの送受信を別に試す

新しいsiteを仮のURLで確認できても、実際のdomainへ切り替えたあとの表示は別に確認します。top pageだけでなく、問い合わせpage、主要な固定page、画像、formの送信先を開きます。example.jpだけではなく、www.example.jpもbrowserで開き、予定した方へ進むかを確かめます。

mailは、web pageが見えるから大丈夫とは言えません。外部のaddressから自分のaddressへ一通送り、受信できるかを確認します。次に、そのaddressから外部へ返し、相手が受け取れるかを確かめます。問い合わせformを使っているなら、formから送ったmailも別に試します。普段のmailとformのmailは、同じように見えても送信経路や差出人の扱いが異なることがあります。

仮に、社内のmailは届いているのにformだけが届かない場合、まずsiteの表示を直す仕事と一緒にしません。formの送信先、差出人、server側の送信設定を調べる仕事として記録します。反対に、formのmailが届いても、担当者のmail addressへ外部から送れないなら、問い合わせだけを見て移転が完了したとは言えません。

確認は、一人が画面を見るだけで終わらせない方が確実です。切替を行った人とは別の人が、外部のnetworkからsiteを開き、mailを送ると、見慣れたbrowserの表示や自分のaccountの状態に引きずられにくくなります。人を増やせない場合は、確認した時刻、使ったURL、送信元と送信先、結果を残します。問題が出たときに、何が見えたのかをたどれます。

切替直後だけで終わらせない

DNSには、得た情報を一定時間保存して使う仕組みがあります。DNSのresource recordには、どれだけ長くcacheできるかを示すTTLが含まれます。そのため、変更直後にある場所では新しいsiteが開き、別の場所では前の情報が残ることがあります。画面が一度正しく見えたことだけで、すべての利用者の状況を断定しません。

切替の日時は、問い合わせが少ない時間だけで決めない方がよいでしょう。問題が起きた場合に、domainのaccountへ入れる人、旧serverを確認できる人、mailを試せる人、制作会社へ連絡できる人がいる時間を選びます。夜間に静かに切り替えても、戻す判断をできる人がいなければ、復旧に時間がかかります。

切替前の設定を控えるのは、単なる保険ではありません。予定どおりに動かないとき、何を比較すればよいかを決める材料です。変更した項目、変更した時刻、確認したURL、mailの送受信結果を一緒に残します。古い設定をその場で消してしまうと、webとmailのどちらの変更で問題が起きたか分けにくくなります。

旧serverをすぐに解約するかどうかも、web siteの表示だけで決めません。広告、印刷物、外部service、古いlinkがどこを向いているか、mailの運用をどこまで確認したかを見ます。費用を早く止める判断と、移転が完了したと確認する判断は別です。契約終了日を先に決めるなら、確認する日と担当も先に決めます。

変更を頼む前に確認責任を渡す

DNSの変更を制作会社へ依頼するときは、「新serverへ向けてください」だけでは足りません。会社側は、外部に案内しているdomain name、残すmail address、変更できないservice、切替後に連絡が取れる人を渡します。制作側は、変更する範囲、作業予定時刻、切替後に確認するURLとmailを返します。

domainのlogin accountを制作会社だけが管理している状態も、長く続けない方がよいでしょう。担当が替わったとき、契約の更新、DNSの修正、緊急時の確認を、会社側が依頼できなくなるからです。passwordをむやみに共有する必要はありませんが、accountの名義、復旧方法、変更を承認する人、現在の設定を確認する方法は残します。

特に、mailを外部serviceへ任せている場合は、siteを移す会社とmailを管理する会社が違うことがあります。誰がどの設定を変更するのかを、切替前に表へ書きます。一方が変更してから他方へ知らせる順序では、原因を追いにくくなります。作業を分けても、判断と確認の記録は会社側へ集めます。

最初の一手は、今使っているdomain nameを一つ取り上げ、web、www、mail、formの四つに分けて、向き先と確認担当を書くことです。その表ができてから、切替の日時と作業内容を決めます。新しいホームページが見えることだけで、移転が終わったとは判断しません。