はじめに
ドメインのDNSサーバ(ドメインの権威を持つ権威DNSサーバ、コンテンツサーバ)が老朽化した場合や、権威DNSサーバの性能増強やインフラ構成見直し等の様々な目的で、新権威DNSサーバへ移行したいといった事があるかと思います。
いわゆるネームサーバの移転、DNSサーバの引っ越し、ドメインの権威DNSサーバを新サーバへ移行するにあたり、個人的に参考になったサイトや書籍をまとめてみました。
なお、本ページ内では、例示用ドメイン名として「example.com」と表記しております。
権威DNSサーバ移行に関する参考書籍
権威DNSサーバ移行に関して、以下の書籍を参考にさせて頂きました。
・DNS & BIND クックブック――ネームサーバ管理者のためのレシピ集
http://www.amazon.co.jp/DNS-BINDクックブック―ネームサーバ管理者のためのレシピ集-クリクット-リュウ/dp/4873111250
144ページ目 「レシピ6.7 あるゾーンのネームサーバを変更する」
・DNS & BIND 第5版
http://www.amazon.co.jp/DNS-BIND-第5版-Cricket-Liu/dp/4873113903
235ページ目 「9.6.2 委任の管理」
権威DNSサーバ移行に関する参考サイト
権威DNSサーバ移行に関して、以下のサイトや投稿を参考にさせて頂きました。
大変参考になりました。ありがとうございました。
・出来る！DNSのお引っ越し！ (http://qiita.com/mickey1982 様が執筆して下さった投稿です)
http://qiita.com/mickey1982/items/715fb1fa93bfa496a969
・ネームサーバ移行 〜虎の巻〜 (http://qiita.com/YamaguchiRei 様が執筆して下さった投稿です)
http://qiita.com/YamaguchiRei/items/280eb9cdd75842c418bd
・DNS浸透の都市伝説を斬る (JPRS 森下泰宏様、民田雅人様の資料です)
http://jprs.jp/tech/material/iw2011-lunch-L1-01.pdf
・DNSの「浸透問題」は都市伝説――正しいサーバー引っ越し法を解説
http://internet.watch.impress.co.jp/docs/event/iw2011/20111201_494798.html
http://internet.watch.impress.co.jp/img/iw/docs/494/798/html/s08.jpg.html
・DNSサーバーの引っ越し ～トラブル発生を未然に防ぐ手順とポイント～
http://jprs.jp/related-info/guide/019.pdf
・DNSサーバの変更の際の手順
http://wp.kaz.bz/tech/2013/04/15/1606.html
・浸透いうな! (通称:DNS浸透問題について)
http://www.e-ontap.com/dns/propagation/
・DNSのおさらいと「ghost domain names」(幽霊ドメイン名)問題について
https://www.nic.ad.jp/ja/newsletter/No51/0800.html
https://www.nic.ad.jp/ja/basics/terms/authoritative-nameserver.html
http://jprs.jp/tech/notice/2012-02-17-ghost-domain-names.html
・「DNS浸透問題」は脆弱性だった！「幽霊ドメイン名脆弱性」
http://www.geekpage.jp/blog/?id=2012/3/21/1
・「なぜDNSの浸透は問題視されるのか」と「5.2. DNS引っ越しの手順」
http://www.geekpage.jp/blog/?id=2011/10/27/1
・ドメイン名のレジストラ変更で、一時的にネームサーバが引けなくなった
http://www.goodpic.com/mt/archives2/2008/12/post_238.html
・DNSのグルーレコードについて
http://misia.sakura.ne.jp/DNSser2.htm
・DNSの「プロパゲーション期間」の説明がアバウト過ぎる件について
http://hetarena.com/archives/255
http://news.local-group.jp/editor/20070823.html#p02
権威DNSサーバ移行時に必要となる大まかな作業の流れ
例えばexample.comドメインの権限を委譲された権威DNSサーバとして、以下のようなネームサーバがあるとします。
old-ns1.example.com.
このexample.comドメインの権威DNSサーバを以下の新サーバへ移行したいとします。
old-ns1.example.com. → new-ns11.example.com.
新権威DNSサーバ「new-ns11.example.com.」の構築やゾーンデータの移行とともに、comドメインのレジストラに対して、上位DNSサーバのexample.comドメインのNSレコードを「old-ns1.example.com.」から「new-ns11.example.com.」へ切り替えて頂く作業も必要になります。
このような場合、すごく大まかでざっくりとした内容ですが、以下のような作業が必要になると思います。
(1) 現権威DNSサーバ(old-ns1)のexample.comゾーンデータを新権威DNSサーバ(new-ns11)へ移行する
・現権威DNSサーバ(old-ns1.example.com.)のexample.comゾーンファイル内のゾーンデータについて、新権威DNSサーバ(new-ns11.example.com.)へ移行する。
(2) 現権威DNSサーバ(old-ns1)と新権威DNSサーバ(new-ns11)のDNS振る舞いテスト
・現権威DNSサーバ(old-ns1.example.com.)と新権威DNSサーバ(new-ns11.example.com.)に対して、現権威DNSサーバのexample.comゾーンファイルに登録している各リソースレコードのDNS名前解決テストを実行し、双方のDNS名前解決結果が同じになる事を確認する。
・権威DNSサーバを構築する場合、新権威DNSサーバ(new-ns11.example.com.)で再帰検索が無効になっている事、不必要なマシンからのゾーン転送要求等をブロックしている事、ソースポートランダマイゼーションが有効になっている等のセキュリティ周りの設定も確認しておく。
・可能ならば、新権威DNSサーバ(new-ns11.example.com.)に対して、負荷テストを実行し、新権威DNSサーバのDNS応答レスポンスやサーバ負荷、DNS統計情報も確認しておく。
(3) 現権威DNSサーバ(old-ns1)のexample.comゾーンファイル内のTTL短縮
・現権威DNSサーバ(old-ns1.example.com.)のexample.comゾーンファイル内のNSレコードやグルーレコード等の各リソースレコードのTTLを短縮する。SOAレコードのネガティブキャッシュのTTLも短縮しておく。
・ただし、一挙にTTLを短縮しすぎると、現権威DNSサーバ(old-ns1)の負荷が予想以上に上がりすぎて、DNSとしての動作に支障をきたす可能性がありうる為、TTLを短縮する場合には、現権威DNSサーバの負荷やレスポンスを確認しながら、TTL1日 -> TTL1時間 -> TTL30分といった形で段階を踏んでTTLを短縮していくと安全かと思います。
(4) (3)のTTL短縮を確認
(5) 現権威DNSサーバ(old-ns1)のexample.comゾーンファイル内のNSレコードを新権威DNSサーバ(new-ns11)へ変更する
・現権威DNSサーバ(old-ns1.example.com.)のexample.comゾーンファイル内のNSレコードについて、現権威DNSサーバ(old-ns1.example.com.)から新権威DNSサーバ(new-ns11.example.com.)へ変更する。
・現権威DNSサーバ(old-ns1.example.com.)のexample.comゾーンファイル内のNSレコード変更後、example.comの名前解決に問題ない事を確認する。
(6) 新権威DNSサーバ(new-ns11)のexample.comゾーンファイル内のTTL短縮
・権威DNSサーバ移行後に問題が発生し、旧権威DNSサーバ(old-ns1.example.com.)への切り戻しが必要になった時に備えて、新権威DNSサーバ(new-ns11.example.com.)のexample.comゾーンファイル内のNSレコードやグルーレコード等の各リソースレコードのTTLを短縮する。SOAレコードのネガティブキャッシュのTTLも短縮しておく。
(7) (6)のTTL短縮を確認
(8) レジストラへ上位DNSサーバに登録されているexample.comドメインの権威DNSサーバ切り替えを申請する
・comドメインのレジストラに対して、comドメインの上位DNSサーバに登録されているexample.comドメインのNSレコードについて、現権威DNSサーバ(old-ns1.example.com.)から新権威DNSサーバ(new-ns11.example.com.)へ切り替えて頂くよう申請する。
old-ns1.example.com. → new-ns11.example.com.
・上位の権威DNSサーバにおいて、example.comドメインのNSレコードのTTL短縮が可能ならば、事前にNSレコードのTTL短縮も依頼する。
・現権威DNSサーバ(old-ns1.example.com.)のセカンダリDNS(スレーブDNSサーバ)の運用をレジストラにお願いしている場合、セカンダリDNSのマスタDNSサーバを現権威DNSサーバ(old-ns1.example.com.)から新権威DNSサーバ(new-ns11.example.com.)へ切り替えて頂くよう申請する。
(注) 上位DNSサーバのNSレコードを切り替えても、TTLが切れるまでの間、各DNSキャッシュサーバ内には古いNSレコードを示すDNSキャッシュが存在し、古い権威DNSサーバにもexample.comドメインのDNS名前解決クエリが飛んでくる事が想定されます。TTLが切れるまでの間は、古い権威DNSサーバにDNS名前解決クエリが飛んでくるので、新旧権威DNSサーバを並行稼動させておく事をお奨めします。もし、TTLが切れるまでの間に、新権威DNSサーバにリソースレコード(例えばwww1.example.comのようなAレコード)を追加するような場合、旧権威DNSサーバにも追加する事をお奨めします。
(9) (8)の上位DNSサーバに登録されているexample.comドメインのNSレコードが新権威DNSサーバ(new-ns11.example.com.)へ変更された事を確認
・dig +norecコマンド等を使用して、上位DNSサーバのexample.comドメインのNSレコードが新権威DNSサーバ(new-ns11)へ切り替わった事を確認する。
(10) 上位DNSサーバのNSレコードが新権威DNSサーバ(new-ns11)へ切り替わった後の動作確認
・インターネット上の各DNSキャッシュサーバやDNSクライアントから、新権威DNSサーバ(new-ns11.example.com.)に対して、example.comドメインのDNS名前解決クエリが飛んでくる事を確認する。
・example.comドメインの名前解決に問題ない事、example.comに関するサイト( www.example.com 等)やメール送受信が正常に動作するか確認する。
・新権威DNSサーバ(new-ns11)のサーバ負荷やDNS応答レスポンスやDNS統計情報を確認し、新権威DNSサーバのリソース状況に問題ないか確認する。
(11) 旧権威DNSサーバ(old-ns1)に対するDNS名前解決クエリ停止の確認
・TTLで指定したDNSキャッシュ保存期間が経過し、インターネット上の各DNSキャッシュサーバやDNSクライアントから、旧権威DNSサーバ(old-ns1.example.com.)に対して、example.comドメインのDNS名前解決クエリが飛んでこなくなった事を確認する。
・example.comドメインの名前解決に問題ない事、example.comに関するサイト( www.example.com 等)やメール送受信が正常に動作するか確認する。
(12) 旧権威DNSサーバ(old-ns1)の停止
・旧権威DNSサーバのDNS名前解決クエリのログファイルを見て、DNSとして利用されなくなった事を確認の上で、旧権威DNSサーバ(old-ns1.example.com.)のBIND等のDNSサーバプログラムを停止する。
・不測の事態が発生した場合等、旧権威DNSサーバへ切り戻す可能性を考慮し、一定期間、旧権威DNSサーバは電源を入れたまま稼動させておくと安全かと思います。
(13) 新権威DNSサーバ(new-ns11)のexample.comゾーンファイル内のTTL戻し
・権威DNSサーバの移行が無事完了し、example.comドメインのWebサービスやメール送受信等の各種サービスに問題なければ、短縮したTTLを元の設定に戻す。新権威DNSサーバ(new-ns11.example.com.)のexample.comゾーンファイル内のNSレコードやグルーレコード等の各リソースレコードのTTL、SOAレコードのネガティブキャッシュのTTLを短縮前の設定に戻す。
ざっくりとした内容で恐縮ですが、以上になります。