## page was renamed from DNS/1/ゾーンサーバ/移転 = ゾーンを移転する = <> [[DNS/1/コンテンツサーバ/移転]] を改名して、内容を更新しています。 {{{ 上位ドメインにおいて委譲のために設定されているNSレコード(とglue)は自分の自由にはならない、 }}} ということをしっかりと認識しておくこと。(いろいろな意味で w) ---- <> 上位サーバーの返すdelegation情報を優先するのが毒盛の危険性をより少なくする。 　つまり、delegation情報を優先するリゾルバーがあってもおかしくない。 ところが、これはNSの移転にとっては都合の悪い事態を引き起こす。(後述) [[/サーバー運営者]] == 分離して作業せよ == {{{ DNS(ゾーン)サーバーの移転とwebサーバーの移転は別々の作業として切り離すこと。 }}} ここではDNSゾーンサーバーだけを移転する場合の注意を説明する。 . webサーバーを移転するときにDNSサーバーの移転を分けて説明するのは面倒だ。w [[web移転]] == delegation 変更 == NS移転の難関はレジストラ(管理画面)を通じてのTLD登録情報の更新かもしれません。 　ここで待たされることも多い。(JPでは15分程度だが、レジストラ、レジストリの運用次第) ゾーンサーバ(ゾーンのNS)は'''''上位ドメイン'''''にNSレコードとして'''''登録'''''されています。 この登録されたNSレコード(またはそのglue)を変更することが「ゾーンサーバを移転/変更する」ということです。 それにはドメインの管理権限をもつことが(登録されている)証明できなければなりません。 証明は通常はレジストラに対して行います。(レジストラは登録変更を代行する業者です。) つまり、'''DNSサーバーの移転'''とは''親に登録したレコード''を変更することを指すものとします。 ''登録レコード''とはNSレコードまたはAレコード(glue)のことです。 (NSレコードがゾーン内の名前の場合にはglueを変更します。) そして、これらのレコードに''対応するゾーン内のレコード''(NSまたはA)も同時に変更するものとします。 これらの変更が短期間のうちに'''見えるかどうか'''を検討するものである。 ゾーンサーバーが他のサーバーを兼ねている場合には、 . ゾーンサーバー機能だけを移転することになる。これをきちんと区別できるかどうかが鍵か。 -- ToshinoriMaeno <> == 移管 == ドメインの管理権限を持っていても、登録情報を書き換えるにはレジストラ(代行業者)を使うことになっています。 　この業者が登録NSの書き換えを制限している場合もあって、そのようなときには[[/レジストラを変更]]する(移管)必要も 　生じます。 == TTL == DNSレコードにはTTLという'''消費期限'''があります。 . ゾーンサーバ側でゾーンデータを変更しても、リゾルバーのキャッシュには以前のレコードが残っています。 ---- D {{{ リゾルバー兼用のゾーンサーバはまずは両者を分離すること。兼用のまま移転はできないと思え。 }}} -- ToshinoriMaeno <> DNSサーバーの移転が瞬時に行われないのにはいくつかの理由がある。 ただし、切り替えに時間がかかろうと気にするひとはいないはずだ。 . webサーバを一緒に移転しようとするから、「浸透待ち」を言うひとが出現する。 -- ToshinoriMaeno <> [[../IPアドレスを変更する]] 場合 ---- 「サーバ移転」でG検索をしてもヒットするのはおかしなページが多いので、コピペでは危ない。 ひとつの理由： 参考：Ghost Domain Names(鬼域名)脆弱性（ゾンビドメイン名とでも訳すると感じが分かる） . [[DNS/脆弱性/GhostDomainNames]] == 移転 == 現時点で 当サイトが勧める方式は [[DNS/1/コンテンツサーバー/移転/手順案]] にあるが、 制約があって守れないかもしれない。 参照側が使っているリゾルバーによっては効果がない。 2012年3月10日現在の結論 . 非協力的運用者の運用するDNSサーバから脱出するための移転であっても、 「浸透を待て」をいうような状況は（原則**）発生しない。 はデマだ。 {{{ 「TTL値に従わないキャッシュが有るので、 ホストの切り替えなどの際には古いサーバはとっとと停止すれば良いかも知れない」 なるほど }}} まあまあの説明をしているページ： https://wp.kaz.bz/tech/2013/04/15/1606.html == 手順だけ守ってもだめだ == 「正しい移転方法」とか「浸透待ち」を回避とかの手順だけ真似てもいいことはない。 === 公式移転手順は面倒 === DNS RFCの要請するとおりに移転する手順はかなり面倒なので、別途書くことにする。 . この手順通りに実行できるケース(人)なら、説明の必要もないだろう。 == DNSの基礎を勉強しよう == 現在のキャッシュサーバの動作を理解すれば、安心して移転できるようになる。 . 『浸透遅い』をいうこともなくなるだろう。 (**) 移転がまったく進行していないようにみえるケース： * 非協力的運用者のサーバには旧サーバを指すNSが旧設定のまま残っている。 * 古い実装のキャッシュサーバ（BIND8など）を参照している人が見ている。 * そのキャッシュサーバに頻繁に当該ドメイン関連のアクセスがある。 jp ドメインではjpサーバが返してくる委譲レコードのTTLは1日だ。 JP登録サーバの変更をしても、旧DNSサーバへの問い合わせは一日は続くだろう。 . 非協力的運用者を使っている（いた）のであれば、あきらめよ。（権威サーバ側でできることはない。） . それ以上続く場合には、キャッシュサーバなどになんらかの問題がある。 {{{ DNSキャッシュサーバがどういう動作をするかは （多くの部分が実装依存という言葉からもわかるように） ばらばらなので、動作確認すらむずかしい。 **ではこういう動作をした、くらいのことでも、 キャッシュサーバのことがよほど分かったひとからの報告でないと参考にならない。 }}} ---- [[DNS/浸透いうな!]]　[[DNS/伝播いうな]] . DNSプロバイダ業者の対応が問題だ。 == 参考資料 == 参考にしない方がよい資料と呼ぶ方がいいかも。 JPRS: http://jpinfo.jp/topics-column/019.pdf [[/JPRS手順]]　 http://www.attn.jp/maz/p/t/pdf/dns-auth-transfer.pdf 「移行の当日」の作業のスライド {{{ 旧サーバでも新サーバに準拠してゾーン情報を更新 }}} == キャッシュ兼用サーバの問題 == キャッシュ兼用のコンテンツサーバを使わせている業者から転出する場合、 . 「浸透待ち」どころか、「浸透しない」問題が発生する可能性がある。[[DNS/浸透いうな論外編]] . [[/兼用サーバリスト]] 兼用サーバーへ移転すると、移転作業時には特に問題が起きているようには見えないかも知れないが、 . とんでもない問題が発生しているかもしれない。（ドメインハイジャック） == 非協力的運用者 == こういう名称まであって、それを前提にしている文書まである。(dnssec.jp) . にもかかわらず、「浸透」問題のことを分かっていないらしい。 DNSプロバイダ業者がだめな業者の場合、上の部分が実行されないので、いわゆる「浸透」問題が発生する。 いまやるべきことはDNSプロバイダがきちんと作業するように働きかけることだ。 . それはJPRSが一番適任なのだが、... [[/脱出法]] == DNS管理者がんばれ == -- ToshinoriMaeno <> 「こういう気持ち悪さがある」: https://twitter.com/#!/kojy/status/141768203809472513 . この気持ち悪さを持つことが大切。 緩和できる。 -- ToshinoriMaeno <> --> [[DNS/コンテンツサーバ/移転/手順案]] まともな記事とは思えないので、読んでいないが、G検索でトップにくるので、リンクだけ。 . https://www.tank-sakurai.com/virtualhost/ コメントはtwitterにお願いします。 -- ToshinoriMaeno <>