## page was renamed from DNS/1/ゾーンサーバ/引越 ## page was renamed from DNS/基礎知識/ゾーンサーバ/引越 ## page was renamed from DNS/基礎知識/ゾーンサーバ引越 ## page was renamed from DNS/基礎知識/引越 ## page was renamed from DNS/引越 <> <> = DNSゾーンサーバの引越 = {{{ DNSサーバとだけ書くと、なにを指しているのか分からないので、ゾーンサーバと呼ぶことにしました。 　自称権威なのに権威サーバと呼びたくないからです。コンテンツサーバ嫌いなひとにも配慮したことになるかも。 }}} == 時間がかかると覚悟せよ == {{{ ゾーンサーバーの移転には時間を必要とすると考えよ。 }}} ゾーンサーバの引越（移転）でのトラブルを避けるにはどうしたらいいか、検討しました。[[/相談受け付けます]] * 移転元の協力が必須です。（と思っていたが、状況次第です） 　　移転に協力的な業者ならば、移転する理由も少ないだろう。w * 移転に非協力的な業者__から__移転することが最重要だと思います。(すでに手遅れ、神頼みかも） * ゾーンサーバだけを移転することで、当該ドメインの管理者以外は気にしないという状況にできます。 [[/時間がかかる理由]] == ゾーンサーバーは引越すな == 引っ越すなと言われても、現在のところに満足できなければ、引っ越すしかありません。 == ゾーンサーバだけを引越す == webサーバーの移転とは分けよ。 証明書取得の都合を考えると、ゾーンサーバー引越を先行させるのがよさそうだ。-- ToshinoriMaeno <> == JPRS手順はまずい == JPRS トピックス&コラム ■DNSサーバーの引っ越し https://jprs.jp/related-info/guide/019.pdf [[/JPRS]] webを同時移転していて、webを巻き込んでいるのでまずい手順である。 == トラブル事例 == [[/booklog.jp]]でのトラブル（障害と書いていますが、ほとんどは管理ミスです。） [[/cocone.jp]] でのトラブル == レジストラの移転とは区別せよ == レジストラの移転については[[DNS/ドメインの管理/移転]]を見てください。 == 移転はトラブルの元と覚悟せよ == DNSホスティング業者のページを見ても、移転手順をきちんと書いてあるものはまれです。 [[レンタルサーバ/引越]] 　素人に説明するのが難しいことは分かりますが、もう少し改善できないものでしょうか。 　すくなくとも一度はお客さんだったわけでしょう。戻ってきてくれるかもしれませんよ。 移行に配慮して記述してある業者のページ（用心しすぎか、脅かしぎみ） 　http://www.at-link.ad.jp/guide/relocation/ == DNS引越の前に == ゾーンサーバの引越でのトラブルの一番は準備不足ではないでしょうか。 　引越するにはするだけの理由があると思います。まずはその理由を整理しませんか。 そのあと、最初にやるべきことは、現状の確認です。 [[/引越の準備]] == ゾーンサーバの変更はレジストリへの変更届けだけでは終わらない == NSレコードの登録を変更しただけでは新しいゾーンサーバに問い合わせがくるとは限りません。 [[DNS/旧サーバが古い返事を返す]]ことがよくあります。 「浸透」という都市伝説が生まれた理由もここにあります。 == 分析 == [[DNS/浸透いうな!]]の元記事中に「DNSの引越し」という言葉が現れるのですが、 その説明はないので、どういうことを指しているのか、勝手に分析してみます。 　e-ontapさんは自身の遭遇した特定の状況（不明）を想定しているらしいので、「引越しとはなにか」は自明なのでしょうけど、 　読者にはその状況が自分の想像しているものと同じかどうかは分かりません。 ゾーンサーバの引越でしょうか。それよりもウェブサーバの引越を想定しているかもしれません。 DNS素人さんがDNSゾーンサーバだけ引っ越すとは想像しづらいので、まわりのサーバも一括して引越すと推測します。 　参考例：[[http://rockwave.ne.jp/support-sv-change.html#summary|サーバ引越しガイド]] 「引越し」が示している内容(ありそうな状況)を推測してみます。(サーバ引越しの延長で） 　引越しというからには現住所にあたるものがあるはずです。 ここの現住所とはなにか。（ゾーンサーバの引越だとしても） 　おそらくDNS(ゾーン）サーバの住所でしょうが、ひょっとしたらキャッシュサーバも含まれているかもしれません。 　単独のキャッシュサーバであれば、その変更はドメイン所有者の関知することではないので、除外されます。 ところで、サーバとはなにか。 　ウェブサーバの引越しとDNS(ゾーン）サーバの引越とは別問題だと考えるべきです。 == ウェブサーバの引越 == 新しいウェブサーバを立ち上げたら、それ（IPアドレス）を指すDNS A レコードを登録するだけです。 　新しい名前ならすぐに見えるはず。IPアドレスの変更であれば、TTLが満了になるまで待てば見えるようになるはずです。 　そうでなければ、運用に問題があるのでしょう。 　ところが、[[http://www.akiplan.jp/hp/qa/qa6.html|ここ]]にも「浸透」時間が必要らしい記述があります。 === slave server の管理がまずいかも === DNSデータを変更したのに、それが当該ドメインのすべてのゾーンサーバ（セカンダリサーバ）に反映されていないのかもしれません。 　確認してみましょう。 最近のBINDであれば、dns-notifyという機能があるそうなので、更新は自然に反映されるはずです。 こういう例も： http://oshiete.goo.ne.jp/qa/57884.html === コンテンツサーバとキャッシュサーバの同居 === DNSコンテンツサーバ（ゾーンサーバ）とキャッシュサーバが同居していても、更新遅延がおきることはないはずです。 ただし、問題の切り分けを簡単にするためには分離しておくことを勧めますが。 == メールサーバの移転 == http://oshiete.goo.ne.jp/qa/5632546.html こういう質問をする人に移転作業をまかせてはいけません。 　　「メールサーバ」の管理にもDNSの知識が必要だということが理解されていないからでしょう。 　　メール管理もあやしい。 = DNSゾーンサーバの移転 = 名前（NSレコード）だけを変更するのなら、利用者にはたいした影響はでないでしょう。 　IPアドレスが変わらなければ、通常の参照には問題がないはずだからです。 そこで、サーバのIPアドレスを含む実体を変更（移転）するものと想定します。 参考： [[DNS/ホスティングサービス]] == DNSゾーンサーバの IPアドレスを変更する == === ゾーンサーバのIPアドレスが上位サーバに登録されているとき === 上位サーバへの登録を変更する必要があることは分かっているものとします。 [[DNS/コンテンツサーバのIPアドレスを変更する]]場合には以下のページが参考になります。 http://djbdns.qmail.jp/djbdns/run-cache-bind-2.html このページはコンテンツサーバとキャッシュサーバ兼用のBINDサーバから分離運用のBINDサーバに移行する 手順を説明したものですので、やや分かりづらいのですが、それなりに役に立つでしょう。 ただし、DNS素人さんには理解しづらいでしょうから、e-ontapさんに書き直してもらうのがよさそうです。:-) -- ToshinoriMaeno <> == TTL は一日か二日 == jp DNS サーバは NS/AレコードなどのTTL を一日（86400秒）にしています。　.com は二日らしい。 上位サーバで指定されているTTLは（自由に）変更はできません。 　したがって、これより短かい時間で切り替えを完了させることは期待しないのがよろしい。 このTTLが満了するときに切り替えさせるためのポイントは {{{ 古い返事をするDNSゾーンサーバを早く停止すること }}} です。 これを守れば、切り替えはすぐに反映されるはずです。 (DNSホスティングでは無理！） 　 {{{ 「浸透」にこれ以上(一週間？）の日時を要すると書いてあるページを信用してはいけません。 }}} 上位のサーバ情報が変更されても、キャッシュサーバに古いゾーンサーバの情報が残っていれば、 古いサーバに問い合わせ続ける可能性があります。（構成によっては、これがずっと続く可能性もあります。） これに対処するために、古い情報を持つコンテンツサーバをとめるのです。 　Ghost Domain Names 脆弱性のあるキャッシュサーバ（いわゆるDNSサーバ）を使っていると、「浸透遅い」に遭遇するでしょう。 権限がないなどの理由で古いサーバを停止できないのであれば、 {{{ 古いサーバのDNSレコードを新しい情報に更新しておくこと。 }}} これもホスティング先によっては難しいかもしれません。(囲い込まれています。）[[レンタルサーバ/DNSサーバ引越]] 　素人管理者には、より難しい問題です。 (dns notifyは使えなさそう) 切り替えのときに「TTLを短くしていく」ということが言われていますが、その理由を理解していますか。 　平行運転できないようなサービスの中断時間を少なくするのが主たる目的のはずです。 　平行運転できるなら、TTLは標準の１日(2日)のままがいいでしょう。 == なぜ古いサーバをとめないのか == 上位のサーバでの登録を含めてサーバのIPアドレスを変更すれば、旧ゾーンサーバへはアクセスしないと思っていませんか。 　そうではないのなら、なぜ旧サーバのDNSレコードも修正しないのですか。 　使わなくなったと思っている旧サーバのことは頭にないのですか。 それともゾーンサーバの管理権限がないのかもしれません。 　管理権限があるのに、移転するというのはかなり特殊な状況なのかもしれませんから。 　[[/こういう対応]]しかしない業者もある。注意しなくては。 DNSが理解されていないと思う所以である。 == キャッシュ兼用DNSサーバからの引越 == [[DNS/兼用サーバからの引越]] 　 = サーバの引越し = [[http://server.612.jp/rental/|いよいよレンタルサーバーの引越し]]を見ると、 {{{ DNSサーバーを切り替えても浸透するまでに数日かかるわけですから古いサーバーはしばらくそのまま残しておかなければいけません。 }}} とあるのですが、肝心のDNS（ゾーン）サーバの切り替えの記述はなさそうです。 　「古い（DNS）サーバー」を残しておくと、ひどいめにあうのですが、その理由の解説は読者への課題とします。 [[http://support.kagoya.jp/manual/move/move_1.html|他社サーバーからの引越しガイド]]はどうでしょう。 こちらは「ネームサーバー情報の変更」があって、NSレコードごと変更するようですが、 　それでも「古いDNSゾーンサーバを止めよ」という記述はない。 (止めるのが簡単だから、こう書いたが、他の方法もある。） そして、以下の記述がある。 :-< {{{ ネームサーバーのDNS情報が世界中の各プロバイダのネームサーバーに反映されるまで、 数時間から1週間ほどの期間を要する場合があります。 }}} [[http://dmget.com/06/04/25-1830.php|ここ]]なども「浸透いうな」のターゲットだ。 ----- 上の段で例にあげたサイトが特にひどいわけではなかった。 -- ToshinoriMaeno <> 検索した結果を見ていてあきれました。（正しく引越しできるページが見当たらない。:-<) 　サーバの引越を商売にしている人のページがこんなに間違っているとは。 　　まあ２週間も待てば、新しい設定の方が使われる確率は100%近くになるでしょうから、 　　よほど変な設定をしていないかぎり問題は消滅するのでしょうけれど。 ----- 以下のページを見かけた。明日、読んでみる。今はリンクだけ紹介する。 　技術者ブログ http://hostingreseller.jp/blog/domainInfo/ * ドメイン関係 ----- DNSゾーンサーバの引越しにはいろいろなトラブルがつきまといます。 　ここまで読んでこられた方には[[DNS/移転するな]]とは言いませんが、気をつけてください。 こういう話もあるようです。http://www.tokyocafe.net/slog/?eid=185 ----- DNSゾーンサーバの引越を手伝います。お酒は飲まないので、対価をいただきます。 相談に応じます。 -- ToshinoriMaeno <>