## page was renamed from DNS/ゾーン/移転手順 ## page was renamed from DNS/ゾーンサーバ/移転手順 ## page was renamed from DNS/移転手順 == DNS/ゾーン/移転手順 == DNS(ゾーン)サーバー移行中も（Webサーバ）利用者には不便な思いをさせることなく、 移転する方法を考えます。 {{{ 新しいゾーンサーバを上位のゾーンサーバに登録するだけで十分です。 非協力的運用者からも簡単に抜け出すことができます。 }}} あまりに単純なので、信じられないひともいるでしょう。　-- ToshinoriMaeno <> 　Ghost Domain Names 脆弱性によって、キャッシュサーバの欠陥が明らかになりました。 　NSサーバ移転時に変更が「浸透しない」などと言われている理由は不良だと判明しています。 == 課題 == いまも残る問題はレジストラがNSレコードのTTL短縮手段を提供していないことです。 　そのために委譲レコードのTTL(JPであれば1日）期間は旧サーバへのアクセスがあると 　考えるべきです。 以下の元の内容は古いので、削除を考慮しています。 ----- == 協力的な運用者間でのDNS移転 == 最大限の[[/協力的ケース]] ゾーン転送を使って、同期させます。 == 非協力的な運用者間でのDNS移転 == いくら非協力的だとしても、以下のことは必要になります。 * 当該ゾーンデータの削除、つまりDNSサーバとしての動作停止です。 　　これは新規サーバの運用を妨げないための最低条件となります。 これすらできないのであれば、非協力というよりも営業妨害だと言われても仕方ないでしょう。 BINDでrestartに時間がかかるから、というのは非協力的になる理由にはならない。(工夫すべき。) あとからの言い訳らしい。 非協力的になる理由に「レンタルサーバ会社の経営事情」をあげるのは詐欺ですと言っているようなものだ。 　そのことすら理解できないのが、DNS業界なのか。 ---- 上記の二つの間には協力の程度によって、いろいろの方法が考えられますが、今後の検討課題です。 　例えば、NSレコードなどを修正して、新しいサーバに向ける。（上位サーバに合わせるのでよい） == なぜ運用者は協力しないのか == DNSホスティングサービスが標準化されていないらしい。 　各社ばらばらの運用をしているらしい。まるで、移転を妨害するかのようだ。DNSSEC導入時の妨げにもなる。 == なぜバラバラの運用なのか == DNSサービスは他のサービスのおまけか。 囲い込みの手段なのか。 == 囲い込み == かつてのメインフレームの時代を思わせる。 　ソフトウェアはハードウェアのおまけであった。有償化という話もあったが、表面的なものだった。 ハードウェアベンダは客を囲い込み、ベンダを移るのは妨害した。 　たしかに、協調なんてなかった。 オープンソースも関係あるかも。 無料は価値がないのとは違う。 -- ToshinoriMaeno <> -- ToshinoriMaeno <>