DNSサーバの変更の際の手順。

いわゆるインターネットで、あるドメイン名のDNSサーバを別のサーバに変更（移行）する際の注意事項やら手順やら。
※DNSについては、様々理解すべきことがあります。
ぜひこちらもご覧ください→ DNSについて。

前提など

[note]
例として下記を前提として書きます。

対象のドメイン名

example.com

現在のDNSサーバ
ホスト名（IPアドレス）

• ns01.example.com（aaa.aaa.aaa.aaa）
• ns02.example.com（bbb.bbb.bbb.bbb）

変更後のDNSサーバ
ホスト名（IPアドレス）

• ns11.example.com（xxx.xxx.xxx.xxx）
• ns12.example.com（yyy.yyy.yyy.yyy）

[/note]

[note]
この記事で言う「DNSサーバ」はいわゆる「権威サーバ」です。
「ネームサーバ」と同義として下記は書かれています。

[追記 2013.08.20.]
「ドメイン」と「ゾーン」という用語が混在していますが、この記事内ではほぼ同義と考えていただいていいと思います。
ただし本来は別物です。
example.com と sub.example.com は親子関係にある「別のドメイン」です。
ゾーンは同一のDNSサーバで管理する1セグメントであり、そのゾーン内にサブドメインなどを含めることができるものです。
移譲をする場合に別ゾーンが発生します。
[/追記]
[/note]

DNSサーバ（ネームサーバ）の変更の意味

「DNSサーバ（ネームサーバ）を変更する」
＝
「上位DNSサーバでそのドメイン名に対して登録されているNSレコード、Aレコード（グルーレコード）を変更する」
＝
「レジストラのネームサーバ登録を変更する」

ということです。
イメージで言えば上位DNSサーバのゾーンファイルの

@example.com
       IN    NS    ns01
       IN    NS    ns02
ns01   IN    A     aaa.aaa.aaa.aaa
ns02   IN    A     bbb.bbb.bbb.bbb

を

@example.com
       IN    NS    ns11
       IN    NS    ns12
ns11   IN    A     xxx.xxx.xxx.xxx
ns12   IN    A     yyy.yyy.yyy.yyy

にする、ということ。

[note]
この上位DNSサーバのゾーンファイルを書き換える権限を持っているのが「レジストラ」です。
上位DNSサーバの管理責任を持っているのが「レジストリ」です。
[/note]

DNSサーバの変更が完了した、と言う状態

DNSサーバはどこかにデータを書き込みに行くような仕組みではないので、世の中の端末からexample.comドメインの名前解決の際に ns11.example.com / ns12.example.com を見にきてもらえるようになることが「変更が完了した」状態と言えます。

そのためには以下の条件が必要となります。

1. ルートDNSサーバ、またはルートDNSサーバから適切に移譲されている上位DNSサーバにある対象ドメインのゾーン情報が適切に書き換わること。（＝「DNSサーバ（ネームサーバ）の変更の意味」で述べた状態になること）
2. 過去に example.com ドメインに対する名前解決をしたことがある端末やその端末に設定してあるリゾルバ（Windowsのネットワーク設定でいう「DNSサーバ」）にあるキャッシュの有効期限が切れること。

1. の状態になることによって、世の中の端末が example.com を名前解決しようとした際に参照するDNSサーバが変更されたことになります。
2. によって、世の中の端末が一度検索した結果のキャッシュを利用せず、改めて名前解決を行うことになります。
その際は1. によって変更後のDNSサーバに対し名前解決を行うことになります。

キャッシュの有効期限

上記 2. の各端末にあるキャッシュの有効期限は、その名前解決を行った時点の TTL です。
仮に TTL が1日に設定されているドメイン名に対して名前解決を行った場合、その時点から1日の間、改めてそのドメインのDNSサーバに名前解決を行うことはありません（キャッシュを削除しない限り）。

つまり、変更を行う直前に example.com ドメインを名前解決した端末が変更後のDNSサーバに問い合わせるのは、変更前のDNSサーバで指定されていた TTL の経過後です。

[warning]
「浸透しない」と言っているみなさん、ほとんどの原因はここを理解できていないことだと思いますよ。
システムは設定されているように動きます。
（設定されているように動かないのは基本的に「不具合」「バグ」です）。
[/warning]

[tip]
実際には、TTLはドメイン（ゾーン）単位ではなく、レコード単位で設定できます。
DNSサーバの変更ではなくレコード単位の変更（IPアドレスの変更など）の際に新しい設定が世の中に参照されるまでの時間も、同じ理由で説明できます。

さらにネガティブキャッシュなどもありますが、今回は割愛します。
[/tip]

（長い前置きの後）実際の手順

以下のような流れで作業を行います。

1. 【TTLを短く変更】
   ns01.example.com, ns02.example.com で設定されているTTL（仮に1日=86400秒）を、短い時間（例えば 5分=300秒）に変更。
2. 元に設定されていたTTL（1日）以上待つ。
   これにより世の中の端末にキャッシュされているデータの有効期限がすべて変更後の時間（5分）になる。
   ※TTLに従わないお行儀の悪い実装については無視。
3. 【新DNSサーバの設定】
   2. を待つ間までに、ns11.example.com, ns12.example.com の設定を ns01.example.com, ns02.example.com と同じ状態にする。
4. ns11.example.com, ns12.example.com に設定されている NSレコード（ns01, ns02が設定されているはず）をns11, ns12 に変更する（シリアルのカウントアップが必要なDNSサーバであればそれも忘れずに）。
   ※この時点でns11/ns12側のTTLは元の状態（1日）に戻しても構いませんが、切り替えの失敗などで切り戻すことを想定すると、まだ戻さない方がいいと思います。
5. 動作テスト。
   新DNSサーバで適切な回答を行うことを確認する。
   例：下記など。

   dig ns @xxx.xxx.xxx.xxx example.com
   dig ns @yyy.yyy.yyy.yyy example.com
   dig a @xxx.xxx.xxx.xxx www.example.com
   dig a @yyy.yyy.yyy.yyy www.example.com
   

   これによって、ネームサーバ登録変更後も正しい動作をする（だろう）ことを期待できる状態になる。

6. 【ネームサーバ登録の変更】
   2. を待った後、レジストラの管理画面などでネームサーバ登録の変更を行う。
   ※お名前でいう「ホスト登録」で ns11（xxx.xxx.xxx.xxx）、ns12（yyy.yyy.yyy.yyy）を登録後、「ネームサーバの変更」で実施。
7. そのドメインのポリシーに応じた待ち時間（.jpなら15分）を過ぎた後、whoisなどで確認。
8. 念のため、上位DNSサーバ（仮にIPアドレスが zzz.zzz.zzz.zzz）に対し動作確認。
   例

   dig ns @zzz.zzz.zzz.zzz example.com
   dig a @zzz.zzz.zzz.zzz www.example.com
   

   期待する結果が返ってくればOK。

9. 【間の悪い端末対策】
   変更前のDNSサーバ（ns01, ns02）のNSレコード設定を ns11, ns12 に変更。
10. 【結果発表】
    短くしたTTL（5分）経過後、動作テスト。
    例：Google Public DNSで。（これが適正に変わっていればかなりの環境で新サーバを利用していることになるでしょう。）

    dig ns @8.8.8.8 example.com
    dig a @8.8.8.8 www.example.com
    

    [warning]
    でも 8.8.8.8 / 8.8.4.4 はオープンリゾルバーと言われる存在すべきでないサービスなので利用しないこと。
    詳しくはGoogleで「オープンリゾルバー」を検索。
    と、JPCERTの「DNS の再帰的な問い合わせを使った DDoS 攻撃に関する注意喚起」 https://www.jpcert.or.jp/at/2013/at130022.html でも。
    [/warning]

11. 気がすんだところで、TTLを元に戻す。

その他

グルーレコードは同一ドメインのものにしましょう。（コメントで指摘をいただき修正）

NSレコードは同一ドメインのもの（内部名）にしましょう。

グルーレコード=ネームサーバのAレコードは同一ドメインのものにしましょう。（グルーの定義など色々間違いがあるので修正)

[追記 2013.08.20.]
そのドメイン（ゾーン)のNSレコードは内部名（そのゾーンと同一のゾーンに含まれるホスト名）にしましょう。

NSレコードを内部名にした場合そのゾーンにとっての親ゾーンまでの情報ではNSレコードにたどりつくことができないため、親ゾーン内にNSに設定したホスト名のAレコードを設定する必要があります。
このAレコードを「グルーレコード」といいます。

外部名（別ゾーンのホスト）のNSレコードの場合、グルーレコードは不要です。
（不要と言うより、害です。）
別ゾーンである以上、そのホスト名は ROOT-SERVERS から別途たどることができるはずであり、外部名はその外部名のゾーンの権威DNSサーバから名前解決されるべきものだからです。
[/追記]

同一ドメインであれば

@example.com
       IN    NS    ns11
       IN    NS    ns12
ns11   IN    A     xxx.xxx.xxx.xxx
ns12   IN    A     yyy.yyy.yyy.yyy

となり、

example.com のNS → ns11.example.com, ns12.example.com
ns11.example.com → xxx.xxx.xxx.xxx

と検索することになりますが、別のドメインである場合、

example.com のNS→ ns11.example.net, ns12.example.net
example.net のNS→ 何らかの返答
返答されたサーバに対しns11.example.net → xxx.xxx.xxx.xxx

と検索することになります。

@example.com
       IN    NS    ns11.example.net.
       IN    NS    ns12.example.net.

と

@example.net
ns11   IN    A     xxx.xxx.xxx.xxx
ns12   IN    A     yyy.yyy.yyy.yyy

の2つのゾーンがあるイメージです。
無駄が多いだけでなく、例えばこの設定を忘れて example.net ドメインだけ廃止したりすると、example.com ドメインの名前解決もできなくなります。

[追記 2013.08.20.]

参考資料

JPRSの森下さんが作られたDNS Summer Days 2013の資料 http://dnsops.jp/event/20130719/20130719-undocumented-DNS-orange-6.pdf
[/追記]

間違い等のご指摘

自分の理解と、いつもの手順をまとめてみました。
間違いなどあるかと思いますが、ご指摘等いただければ幸いです。