## page was renamed from DNS/1/コンテンツサーバ/移転/手順案 ## page was renamed from DNS/基礎知識/コンテンツサーバ/移転/手順案 ## page was renamed from DNS/コンテンツサーバ/移転/手順案 <> == DNS/コンテンツサーバ/移転/手順案 == 警告：このページは古い。 　リゾルバーの動作に依存している。（それも、毒盛されやすくなる脆弱性につながる。） [[../JPRS手順]]に感じる気持ち悪さ（＊）を解消するには以下のようにする。 　(＊）上位から委譲されているはずのサーバの返事に当該サーバが含まれていない状態） NSレコード(と付随するAレコード)以外の移転は別途行うものとする。-- ToshinoriMaeno <> 準備段階： {{{ 手順 1:　引っ越し先の DNS ゾーンサーバの構築(NSとしては引越し元、引越し先の両方を含めておく) 手順 2:　引っ越し元ゾーンに引越し先の DNS ゾーンサーバをNSに「追加」する （セカンダリサーバがあれば、追加が反映される。） }}} 双方の DNS ゾーンサーバを並行運用: ここまでで新サーバが追加されて、引越し準備ができたことになる。 上位サーバ登録を変更する。 {{{ 手順 3:　（親に）登録してある委譲（委任）情報に引越し先を追加する。（新サーバが正式に使われる） 手順 4:　双方の DNS ゾーンサーバの並行運用を継続する }}} 委譲（委任）情報に新サーバが見えるようになったら、 {{{ 手順 5:　親に登録した委譲（委任）情報から引越し元サーバNSを削除する。 }}} ＊）引越し元はキャッシュに残っている可能性がある。 上位からの委譲が新サーバだけになるのを待って、DNSゾーンデータから旧サーバNSを削除する。 {{{ 手順 6:　引っ越し元である DNS ゾーンサーバNSを「削除」する。(引越し元、引越し先両方;並行運用続行) }}} ＊）引越し元はキャッシュに残っている可能性がある。　 　引越し元のゾーンをいつ削除するのがいいかはむずかしい問題である。-- ToshinoriMaeno <> 最後に旧サーバの停止： {{{ 手順 7:　引っ越し元のDNSゾーンサーバの停止 }}} 旧サーバを停止するのが望ましいが、難しいかもしれない。その場合にはなんらかの問題が発生することがある。覚悟が必要だ。 委譲されたはずの権威サーバが自身を含まないNSを返答するという「気持ちの悪い状態」を発生させないためにここの手順を考えた。 キャッシュの有効な期間の親からの委譲の不一致をどう考えるか。 新旧両方の委譲が有効だと解釈するのが自然だろう。 ---- == lame delegation == 親がNSで示した権威サーバの集合と子が示した権威サーバの集合の不一致をどこまで認めるかについては 意見が分かれているようだ。 (通常の状態では)親が委譲した権威サーバの返す返答には自身が含まれているべきであるというのがRFCにあった。 ただし、RFCではDNSサーバの移転には触れていない。 移転中でもRFCに準拠した状態を維持できるという証明はされていない。 == 非協力的運用者 == NSレコードを利用者が設定できないDNSプロバイダが存在する。 これらのプロバイダは円滑な移転を妨害することを目的に制約していると解釈できる。 -- ToshinoriMaeno <> そういう業者を指導するのはレジストリの仕事のはずだ。 == 引越し元のゾーンをいつ削除するか == 削除しないとおきる問題としては、いわゆる「浸透しない」と言われるような問題を抱える脆弱なキャッシュサーバでおきるものがある。 　これは不良を抱えたキャッシュサーバ側の問題であるので、移転側は気にしなくてよいだろう。 削除が早すぎると： 共用DNSサービスを利用していた場合には乗っ取りの危険がある。詳しくは説明しない。 -- ToshinoriMaeno <>