## page was renamed from DNS/管理/引越 <> ---- = DNS/管理/引越 = <> [[DNS/1/ゾーンサーバ/引越]] [[/cloudflareへの移転]] なぜ移転(引越)するのでしょう。 　正しい？引越手順が実行できるとは限らないことが落ちている。 ゾーンサーバの引越手順を考察します。 -- ToshinoriMaeno <> 　JPRS推奨の引越し手順には惑わされないように。（キャッシュサーバの実装不良を前提の手順はまやかしです。） 以下の操作が必要です。短期間に終えるには手順が重要です。 0. 新サーバを用意しておく。（設定を含めて） 1. 委譲元（上位）に登録しているTTL情報を短縮する。（ここが一番重要です。） 　　JPドメインに関して、JPでは登録情報のTTLを登録者が変更することを許していません。2015-10-31現在 2. 旧ゾーンサーバの情報を変更する。（新サーバをNSに追加する） ３. 委譲元（上位）に登録しているNS情報を新サーバに変更する。 ４. 古いゾーンサーバ（の情報）を削除する。古いゾーンサーバ（の情報）を削除する。 　　古い情報が残っていると影響を受けるリゾルバーが存在します。 手順を工夫する理由は少なくとも二つあります。 1. キャッシュサーバによっては古い情報を使い続けるという不良（GDN脆弱性）があったりします。 2. 非協力的事業者の存在です。（いなくなる客の情報の変更には対応しないというもの） 　　あるいはNSレコードやグルーの変更には対応しないというものです。 {{{ JPゾーンの管理方針が敏速な移転を妨げています。 (TTLの変更を許していない） }}} .com なども同様かもしれません。　 ---- 二つの場合に分けて検討します。（毒盛のしやすさとBINDキャッシュの動作とに影響しそうだからです。） == ゾーンサーバの名前とIPアドレスを変更する == == ゾーンサーバのIPアドレスだけを変更する == IPアドレスが変わったことをキャッシュはいつ、どうやって検知するでしょう。 　上位サーバ（委譲元）を確認するのはいつでしょう。 旧ゾーンサーバを参照し続けるキャッシュサーバ（実装）はないでしょうか。 {{{ 引越作業中は毒盛されやすくなるので、監視を怠らないことです }}} ---- -- ToshinoriMaeno <> 以下のおかしな手順が前提としているものを推測してみてください。 http://jprs.jp/related-info/guide/019.pdf {{{ 手順1：引っ越し先の権威DNSサーバーの構築 手順2：引っ越し元の権威DNSサーバのゾーンデータの切り替え 手順3：親に登録した委任情報の切り替え 手順4：双方の権威DNSサーバーを並行 }}} DNSサーバの移転で重要とされているTTLの短縮という話がでてきませんね。 -- ToshinoriMaeno <> [[/AmazonRoute53への移転]] http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/MigratingDNS.html