その上で分かったDNSサーバの移行（ゾーン情報の移行）の方法について、今後の自分のためにメモを残しておきたいと思います。
覚えておきたい基礎知識
下記のようなサイトを見て学習しました。まずは「○○レコードってなんぞや？」というところを理解する必要があります。その次に、「じゃあ、具体的にどういう流れで移行すればいいんだ？」というところを調べていきます。
- SOAレコードには何が記述されている？ [[http://www.atmarkit.co.jp/fnetwork/dnstips/014.html]]
- 主なDNSレコードの種類 [[http://www.atmarkit.co.jp/fnetwork/rensai/dns01/dns-record.html]]
- DNSサーバーの引っ越し～トラブル発生を未然に防ぐ [[http://jprs.jp/related-info/guide/019.pdf]]
- ネームサーバ移行 ～虎の巻～ [[http://qiita.com/YamaguchiRei/items/280eb9cdd75842c418bd]]
- LT資料 (夏のDNS祭り 2014 ～入門セミナ＆ハンズオン～) [[http://qiita.com/tukiyo3/items/18411315a05b80e574bc]]
1．移行元ゾーンの様々なTTLを怒られない程度に短くする（移行2日前など）
まずは自社のBIND内のゾーンの色んなTTLを可能な限り短くします。
AレコードやNSレコードはもちろんのこと、SOAレコードのTTLも短くしてください。
目安としては、AレコードやNSレコードは300秒程度まで減らしてください。
SOAレコードは複数種類のTTLがありますが、それぞれ10分の1程度まで減らします。
個体差はあると思いますが、1日もあれば短くなったTTLで各DNSサーバの情報が書き換わっている（更新した情報が浸透できている）と思いますので、変更作業実施予定日の2日前ぐらいにはやっておきたいところです。
AレコードやNSレコードはもちろんのこと、SOAレコードのTTLも短くしてください。
目安としては、AレコードやNSレコードは300秒程度まで減らしてください。
SOAレコードは複数種類のTTLがありますが、それぞれ10分の1程度まで減らします。
個体差はあると思いますが、1日もあれば短くなったTTLで各DNSサーバの情報が書き換わっている（更新した情報が浸透できている）と思いますので、変更作業実施予定日の2日前ぐらいにはやっておきたいところです。
変更値の目安（これくらいまで短くしてください）
Aレコード … 300秒
NSレコード … 300秒
MXレコード … 300秒
TXTレコード … 300秒
SOAレコードのRefresh … 600
SOAレコードのRetry … 300
SOAレコードのExpire … 6000
SOAレコードのNegative cache TTL … 300
NSレコード … 300秒
MXレコード … 300秒
TXTレコード … 300秒
SOAレコードのRefresh … 600
SOAレコードのRetry … 300
SOAレコードのExpire … 6000
SOAレコードのNegative cache TTL … 300
SOAレコードは特に’‘Negative cache TTL’‘を短くすることが大切です。これが短くなってると、もしなんかのミスで「そんなサーバ存在しねーよ」状態になってもNegative CacheのTTLの間隔で更新することが可能になります。
2．移行元を停止せずに移行先にゾーン情報をコピーする（移行2日前）
コピー方法はいろいろありますが、移行先サーバを作成して、そこに移管したいゾーンと全く同じ情報を登録します。
すみません、すべての情報のうち、移行元のDNSサーバー自身に関する情報は不要です。
すなわち、DNSサーバーを指し示すAレコードや、CNAME、NSレコードなどです。
すみません、すべての情報のうち、移行元のDNSサーバー自身に関する情報は不要です。
すなわち、DNSサーバーを指し示すAレコードや、CNAME、NSレコードなどです。
BINDからAWS Route53への移行方法としては、Perlのスクリプトを使う方法が有名みたいです。しかし、この記事執筆時の移行元BINDサーバは、なぜかそれが使えなかったため、手動でコピーしました。ゾーンが数十など行くようであれば、どうにかしてツールでコピーすることをお勧めします。
3．移行先ゾーンの様々なTTLを怒られない程度に短くする（移行2日前）
移行先のゾーンのTTLも短くしてください。短さの程度は移行元と同じ程度で構いません。
理由は、移行の際に移行先ゾーンのTTLも短いと、設定漏れ内容の再設定を行うカバー作業の時間が短縮されるためです。
移行が完了したら、世の中のためにデフォルト値に戻しておきましょう。
理由は、移行の際に移行先ゾーンのTTLも短いと、設定漏れ内容の再設定を行うカバー作業の時間が短縮されるためです。
移行が完了したら、世の中のためにデフォルト値に戻しておきましょう。
4．移行元のゾーン情報に移管先のDNSサーバをNSレコードで登録する（移行2日前）
移行元のBINDサーバのゾーンに、移行先のDNSサーバをNSレコードとして登録します。
それにより、一時的に「DNSサーバの仲間が増えたから紹介するぜ！」状態になります。
つまり、レジストラの管理画面からWhois情報変更後に、古い情報を元に移行元サーバへ
問い合わせを行ってきたエンドユーザーに対して、応答可能なDNSサーバな1つとして、
移行先のサーバを紹介することができ、アクセスが途切れるのを防ぎます。
これをやっておかないと、さまざまなキャッシュが消えるまで全く接続できない状態になります。
それにより、一時的に「DNSサーバの仲間が増えたから紹介するぜ！」状態になります。
つまり、レジストラの管理画面からWhois情報変更後に、古い情報を元に移行元サーバへ
問い合わせを行ってきたエンドユーザーに対して、応答可能なDNSサーバな1つとして、
移行先のサーバを紹介することができ、アクセスが途切れるのを防ぎます。
これをやっておかないと、さまざまなキャッシュが消えるまで全く接続できない状態になります。
5．移行先のサーバが世に出たことを確認する（移行1日前）
nslookup(dig)テスト【DNSサーバ接続確認】（[[http://www.cman.jp/network/support/nslookup.html]]）
などを使って、移行先のサーバが移行元サーバの新しいNSレコードとして追加されたかを確認する。
追加されていれば、前述の「DNSサーバの仲間が増えたから紹介するぜ！」状態になっていると言えます。
などを使って、移行先のサーバが移行元サーバの新しいNSレコードとして追加されたかを確認する。
追加されていれば、前述の「DNSサーバの仲間が増えたから紹介するぜ！」状態になっていると言えます。
6．レジストラの管理画面からDNSサーバを移管先へ変更する（移行1日前）
お名前.comやムームードメインの管理画面へログインし、DNSサーバー（ネームサーバーと書かれていることも）の設定内容を変更します。
自社でDNSサーバーを運用している場合は、そのDNSサーバーが設定画面に書かれていると思いますので、 その内容を移行先のDNSサーバーのものへ更新します。
‘’これが実質的な「移行開始作業」’‘となり、ここから色んなキャッシュがクリアされるまで、いわゆる「長ければ数日、 サイトが見れなくなる」可能性があります。
自社でDNSサーバーを運用している場合は、そのDNSサーバーが設定画面に書かれていると思いますので、 その内容を移行先のDNSサーバーのものへ更新します。
‘’これが実質的な「移行開始作業」’‘となり、ここから色んなキャッシュがクリアされるまで、いわゆる「長ければ数日、 サイトが見れなくなる」可能性があります。
7．旧サーバが参照されていないことを確認する （移行2、３日後）
TTLを確認して、切れたタイミングでDNSサーバー接続確認を再度行ってください。
SOAレコードおよびその他すべてのレコードの情報が移行先のDNSサーバーで設定したものとなっていれば、
移行は完了しています。それを確認した後、移行元DNSサーバからゾーン情報を削除するなり、
移行元DNSサーバーを停止するなりしてください。
もしものために、ゾーン情報を削除したり、サーバー自体を削除したりする前に、一度停止してみることをオススメします。
以上、これでいつかまた自分がDNSサーバの移行をやらなきゃいけなくなった時に、自分の記事を見てなんとかできることでしょう。未来の俺、検討を祈る。
SOAレコードおよびその他すべてのレコードの情報が移行先のDNSサーバーで設定したものとなっていれば、
移行は完了しています。それを確認した後、移行元DNSサーバからゾーン情報を削除するなり、
移行元DNSサーバーを停止するなりしてください。
もしものために、ゾーン情報を削除したり、サーバー自体を削除したりする前に、一度停止してみることをオススメします。
以上、これでいつかまた自分がDNSサーバの移行をやらなきゃいけなくなった時に、自分の記事を見てなんとかできることでしょう。未来の俺、検討を祈る。