弊社では数年間オンプレミスDNSを管理していました。

オンプレミスで問題となるのが停電です。瞬断はUPSで何とかなりますが、長時間停電や回線ダウンまで考慮すると対策が難しいですし相応のコストがかかります。

ということでクラウドにお引越ししました。

DNS浸透問題など色々心配ごとはありましたが、何の問題も起きませんでした。もう停電を気にしなくてよいので非常に気分がよいです。

かなり簡単な作業だったので、メモを兼ねてご紹介しようと思います。

AWSのDNSサービスがRoute 53

引越し先として、Route 53を選択しました。Route 53はAWSのDNSサービスです。

ちなみにRoute 53の由来は、Amazon本社が53号線沿いにあるから・・・ではありません。単にDNSが53番ポートを使うからだそうです。ほほう。

１． Route 53でやること

Route 53に正引きゾーンを作成する

オンプレミスDNSの設定をインポートする

弊社のオンプレミスDNSはBINDだったのですが、ゾーンファイルをRoute 53の設定画面に直接貼り付けられます。大量のレコードがある場合はとても楽ちんです。

NSのTTLとSOAのTTL・ネガティブキャッシュを短縮する

後で元に戻すので、現在の設定値を覚えておきます。

そして全部300s（5分）にします。

２． オンプレミスDNSでやること

NSのTTLと、SOAのTTL・ネガティブキャッシュを短縮する

全部300sにします。

Route 53のTTLと同じ値にすることがポイントです。

どうして短縮するのか

通常運用時のTTLはだいたい1〜2日です。クライアントがDNSで名前解決すると、次にDNSにアクセスするのは１〜２日経過後です。

この状態でレジストラのDNS設定をオンプレミスDNSからRoute 53に変更しても、各クライアントがRoute 53にアクセスするようになるまで最長で１〜２日かかってしまいます。

これがDNSの浸透の正体です。

切り替わるまで時間がかかるんだよねーという会話を聞いたら、手順が間違っているんだなと思ってください。

TTLを事前に短縮するなど、ちゃんと手順を考えてやれば浸透問題は起きません。

オンプレミスDNSのTTLが期限切れになるまで待つ

変更前の設定値の時間が経過するまで待ちます。

経過すると、クライアントが短時間（最長５分）で再度DNSに問い合わせする状態になります。

nslookupでTTLが300になっていることを確認

時間が経過していれば、新たなTTLの値が取得できるはずです。

NSをRoute 53の設定値にする

Route 53のNSレコードの設定値を、オンプレミスDNSのNSレコードに設定します。

同じ権威DNSサーバを設定するので、切り替えのタイミングが悪いクライアントがいたとしても問題は発生しません。

３． ドメインのレジストラでやること

ドメインのDNSホストをRoute 53に変更

ドメインのレジストラの設定画面で、オンプレミスDNSからRoute 53のDNSサーバに変更します。

Route 53のNSレコードに設定されている4つの権威DNSサーバです。

プロバイダにドメイン取得を代行してもらっている場合は、プロバイダの設定画面で操作することになるはずです。

これでオンプレミスDNSからRoute 53に切り替わります。

４． 確認＆後片付け

あとは確認して、後片付けをするだけです。

問題ないか確認

最低限、以下のような確認をします。

nslookupで名前解決ができて、Route 53のDNSを向いているか？

ホームページが見られるか？

メールの送受信ができるか？

（Office365を使っている場合）Skypeが使えるか？

Route 53のNSのTTLとSOAのTTL・ネガティブキャッシュを元に戻す

事前にメモしておいた値に戻します。

オンプレミスDNSを停止

もう参照されていないので止めましょう。

最後に

いかがだったでしょうか。

メモレベルではありましたが、意外に簡単だということはお分かりになったと思います。

もし同じような面倒を抱えているなら、思い切ってクラウドに移行するのはいかがでしょう。