Web・メールサーバの移行作業はDNSから始まります。
今回は移行時のDNS設定の確認方法と移行作業で一番重要なDNSレコードのTTL値についてご報告します。
発端となったのは…
レンタルサーバのサービス終了に伴い、3か月計画くらいで移行を実施することになりました。
こういうときは移行先サービスをまずは比較検討します。
だいたい3社くらいの候補で比較検討になりますね。
また、現行のDNSサーバのAレコードとCNAMEレコードしか利用できない、という制限事項があるので、DNSも乗換することになりました。
DNSのレコード設定次第でサーバの切り替えによるダウンタイムは極小化することが可能になります。このため、まずはフルスペックのDNSが安定稼働するようDNS切り替えを実行しました。
新DNSサービスを用意したのち、旧DNSと並行稼働させます。
ゾーン転送などは出来ないので、旧DNSに登録してあったレコードを新DNSサーバに手作業で入力します。
移行に関しては新環境と旧環境が一定期間並行稼働するのは基本です。新環境に問題があれば旧環境にすぐ切り戻しすることと、新環境の動作が旧環境と相違した場合に旧環境の設定や環境を確認し新環境に反映するためです。
レコード設定が同一になったことを確認するために、端末からnslookupコマンドを実行して確認します。
実行結果の出力は以下の名前になります。この文書を参照する場合には各々の環境に読み替えて確認ください。
DNSレコード状況（今回は新旧共通です。）
www IN A XXX.XXX.XXX.151
@ IN A XXX.XXX.XXX.151
@ IN MX 10 userdomain.co.jp
コマンドプロンプトで「nslookup」を実行してnslookupコンテキストに移ります。
nslookupコマンドの待ち受けで「server %DNSホスト名%」と入力して名前解決を実行してくれるDNSを指定します。
■画面例：（こんな感じ）
----------------------------------------------
C:\Users\username>nslookup
既定のサーバー: defaultdns.userdomain.co.jp
Address: XXX.XXX.XXX.X
> server olddns.domain.ne.jp
既定のサーバー: olddns.domain.ne.jp
Address: XXX.XXX.XXX.X
>
----------------------------------------------
上記だと名前解決は旧DNSサーバに名前解決を依頼することになります。
コマンドプロンプトを2つ開き、旧DNSと新DNSに名前解決要求を発行し同一の値が返されることを確認するのです。
同一の値が返されるのであれば、二つのDNSサーバは同一の名前解決を提供できる、ということになります。
----------------------------------------------
■Aレコードの確認
----------------------------------------------
> www.userdomain.co.jp
サーバー: olddns.domain.ne.jp
名前: www.userdomain.co.jp
Address: XXX.XXX.XXX.151
> userdomain.co.jp
サーバー: olddns.domain.ne.jp
名前: userdomain.co.jp
Address: XXX.XXX.XXX.151
----------------------------------------------
> www.userdomain.co.jp
サーバー: shindns.domain.co.jp
名前: www.userdomain.co.jp
Address: XXX.XXX.XXX.151
> userdomain.co.jp
サーバー: shindns.domain.co.jp
名前: userdomain.co.jp
Address: XXX.XXX.XXX.151
----------------------------------------------
DNS設定で、
www IN A XXX.XXX.XXX.151
@ IN A XXX.XXX.XXX.151
と設定していたのであれば、上記の出力結果で新旧のDNSが同一の値を返すはずです。
この値が相違するようであれば、Aレコードで指定した値が間違っていますし、解決できないエラーメッセージであれば、ホスト名入力が間違っています。
----------------------------------------------
■MXレコードの確認
----------------------------------------------
> set type=mx
> userdomain.co.jp
サーバー: olddns.domain.ne.jp
userdomain.co.jp MX preference = 10, mail exchanger = userdomain.co.jp
userdomain.co.jp nameserver = olddns.domain.ne.jp
userdomain.co.jp nameserver = olddns2.domain.ne.jp
userdomain.co.jp internet address = XXX.XXX.XXX.151
----------------------------------------------
> set type=mx
> userdomain.co.jp
サーバー: shindns.domain.co.jp
userdomain.co.jp MX preference = 10, mail exchanger = userdomain.co.jp
userdomain.co.jp nameserver = shindns2.domain.co.jp
userdomain.co.jp nameserver = shindns.domain.co.jp
userdomain.co.jp internet address = XXX.XXX.XXX.151
----------------------------------------------
電子メールの送受信に必要となるMXレコードの設定確認です。
最初に「set type=mx」としてmxレコード確認モードに変更します。ドメイン（電子メールの@以降）を入力して確認すると、メールの配送先がどこかを教えてくれます。
これも出力結果で新旧のDNSが同一の値を返しているので無事設定できているようです。
----------------------------------------------
■NSレコードの確認
----------------------------------------------
> set type=ns
> userdomain.co.jp
サーバー: olddns.domain.ne.jp
userdomain.co.jp nameserver = olddns2.domain.ne.jp
userdomain.co.jp nameserver = olddns.domain.ne.jp
>
----------------------------------------------
> set type=ns
> userdomain.co.jp
サーバー: shindns.domain.co.jp
userdomain.co.jp nameserver = shindns2.domain.co.jp
userdomain.co.jp nameserver = shindns.domain.co.jp
>
----------------------------------------------
最後は出力結果が異なることを確認します。
つまりドメイン「userdomain.co.jp」の名前解決を実行してくれたDNSは各々新旧のDNSが処理してくれたかどうかの確認です。
olddns.domain.ne.jpからshindns.domain.co.jpに切り替えるために必要になります。
同一のレコード情報を応答してくれることが分かったところで、いざドメインに紐づくDNSを切り替えます。
DNSサーバの切り替えについて具体的な作業については、現在のドメイン管理事業者側に確認する必要があります。
恐らく、契約者向けのWebインターフェースなどあるのではないかと思います。紙面の申請書形式のところもあるようです。
私はweb画面から変更を実行するタイプだったので、管理画面ログイン後DNSの名前を変更しました。
旧DNSサーバ入力値
olddns.domain.ne.jp
olddns2.domain.ne.jp
を、新DNSサーバに変更掛けました。
shindns.domain.co.jp
shindns2.domain.co.jp
これで、ドメイン管理事業者所定の待ち時間を経過するとDNSサーバが変更されます。
変更が実行されたかどうかを確認するにはローカルイントラDNSで名前解決する状態で、
----------------------------------------------
C:\Users\username>nslookup
既定のサーバー: defaultdns.userdomain.co.jp
Address: XXX.XXX.XXX.X
> set type=ns
> userdomain.co.jp
----------------------------------------------
これをもう一度実行します。
※検証時は「server %DNSホスト名%」としてDNSサーバを指定しましたが、ドメインのDNS切り替え後の確認ではこのserverコマンドでDNSサーバ指定はしません。現在インターネット上に伝播しているNSレコードの状況を確認する必要があるので、そのままNSレコード指定でドメインの名前解決を実行します。
「NSレコードの確認」で出力された結果のうち、新DNSサーバ側の出力結果が表示されればDNSサーバの移行完了となります。逆に旧DNSサーバが表示されるままであれば移行は完了していません。
また確認その2として、新DNSサーバにだけ
test IN A XXX.XXX.XXX.151
などとAレコードを作成しておいて、「test.userdomain.co.jp」の名前解決をしてみましょう。
旧DNSに存在しないAレコードを作成して名前解決することで、名前解決を実行するDNSが新DNSに変わった、ということが確認できます。
レコード情報は同一のはずですが、念のためブラウザから「www.userdomain.co.jp」にアクセスしてホームページがアクセスできることと、メールの送受信を実行してDNS切り替えの影響がない、ということを確認しておくとなおよいです。
補足：TTLについて
ここからはDNSレコード編集内容を短時間で反映させるための方法です。
DNSレコード設定時にTTLという設定値があります。
正確には、DNSのレコード設定は以下のような入力になります。
--------------------------------------
HOST TYPE TTL IPAddress
+-----+--+---+------+----------------+
www IN A 86400 XXX.XXX.XXX.151
--------------------------------------
TTLとはキャッシュ機能で保持するDNSレコード情報のタイムアウト値です。各DNSサーバでは取得したホスト名とIPアドレスのレコード情報をメモリ上に一時保存します。再度問合せがあってもキャッシュの有効期間が切れるまでは問い合わせを行わずキャッシュされた内容を返す動作をします。
このTTLで指定した値が「私のドメインのこのレコードはTTLで指定した時間だけキャッシュしてくださいね。」とインターネット上の全DNSサーバに宣言するような動作をします。
値の86400とは何かというと、秒数です。
86400秒=1440分＝24時間＝1日です
つまりこの「www」というホスト名のレコードは、IPアドレスがXXX.XXX.XXX.151の状態をインターネット上の全DNSサーバで1日保持される、ということになります。
ようするに、いくら自分でDNSサーバのレコードを変更しても、1日は変更出来ない、ということです。
移行時の作業はこのTTL値がとても重要になります。
www IN A 86400 XXX.XXX.XXX.151
このレコードを
www IN A 86400 XXX.XXX.XXX.181
と変更する必要があった場合、あらかじめTTL値を短く入力しておきます。
■1段階目：前日以前にTTL値を変更します。
www IN A 300 XXX.XXX.XXX.151
※ここでは300秒に指定し、5分を有効期限にしています。
■2段階目：実際のレコード値を変更します。
www IN A 300 XXX.XXX.XXX.181
前日以前でTTL値を300秒としていたので、レコードをXXX.XXX.XXX.151⇒XXX.XXX.XXX.181に変更したのち5分待てばインターネット上のDNS全体に伝播されることになります。（※実際の伝播はリクエスト発行後ですが）
切替が終われば（もちろん必要な正常動作確認を実行してDNSを使うシステムに誤動作がないことを確認するのが前提です。）キャッシュ有効生存期間を変更します。
■3段階目：TTL値を戻します。
www IN A 86400 XXX.XXX.XXX.181
経過観察のためTTL値を86400に戻すのは数日経過後かもしれませんが、最終的にはTTL値は戻しておくことが推奨されます。（5分おきにリクエストがきてDNSはそれを処理しなくてはならない状態ですから）
DNSサーバがキャッシュを参照しているタイミングで実際のネットワーク構成が変わるとどうでしょう？
上記例でいえば「www.userdomain.co.jp」にアクセスすると、XXX.XXX.XXX.181が参照されなければアクセスできないのに、XXX.XXX.XXX.151に対してアクセスし続けます。このため並行稼働期間が必要になります。TTLが長いと実際に手作業で変更しかけたのち、並行稼働期間が延びることと【無駄な待ち時間】によってテスト工程が遅延します。
この変更を最小限の時間で完了させるのが自ドメインのTTL値を小さくしておく、という動作です。
ただしTTLが短い秒数である設定が恒常化してしまうとDNSサーバに負荷が掛かります。しかも自社だけでなく他者or他社のDNSサーバにも負荷が掛かります。自社のスペックが高いからDNSサーバのTTL値は少なくて大丈夫、という類の設定ではありません。（だって他社のDNSサーバのスペックなんてわからないでしょう？）
このため移行作業が完了すればTTL値は長く（1日あるいは3日～1週間くらいが一般的なようです。）取っておくことが推奨されています。
要約すると、
- Web/メールサーバの移行時はDNSが重要。
- 新旧同じ環境を用意して、TTLを最小限にし一気に切り替える。
※新旧同じ環境を用意する、というのはDNSサーバ移行でもWeb/メールサーバ移行でも同じです。 - 一気に切り替えるので、旧環境の機能をもれなく新環境側に実装するようにする。ここには時間が掛かるがしっかりやること。
こんなところでしょうか？
次回作業はWebメールサーバの切り替えを実施する予定です。
