1. 移転/JPRS手順

Contents

移転/JPRS手順

https://jprs.jp/related-info/guide/019.pdf (2011)

この手順は正しいわけでもないし、問題が発生しないわけでもない。

　最大の問題はwebサーバーの移転とDNSサーバーの変更(移転)を絡ませてしまったことにある。

「DNSサーバーの引っ越し」とはと言いながら、

    すべての権威DNS サーバーのホスト名とIPアドレスが変更される
    Web サーバーやメールサーバーなど、権威DNSサーバー以外のサーバーのホスト名は変更されず、IP アドレスのみが変更される

また、上位サーバのTTLが短縮できないことには触れていない。レジストリとしてのJPRSにとって都合の悪い話だから。

手順４ 親の権威DNSサーバーのNSで指定されていたTTL値（親のNSのTTL)

-- ToshinoriMaeno 2016-11-30 02:19:42

そして、非協力的事業者の存在だ。

移転元のDNSサーバーで、NSレコードの設定ができなかったり、TTLの短縮ができなかったりする業者が存在する。

1.1. 手順項目

手順 1:引っ越し先の権威 DNS サーバーの構築
手順 2:引っ越し元の権威 DNS サーバーのゾーンデータの切り替え
   引っ越し元の権威 DNS サーバーのゾーンデータを、NS の指定やグルーレコードの指定なども含め、
      まるごと新しいゾーンデータに切り替えます
手順 3:親に登録した委任情報の切り替え
手順 4:双方の権威 DNS サーバーを並行運用
手順 5:引っ越し元の権威 DNS サーバーの停止

Internet Watchの記事では「正しいサーバー引っ越し法」として紹介されているとある。

1.2. この手順が正しい手順か

かなり疑問がある。気持ち悪い部分があるということで、../手順案を作ってみた。

RFC 1034 4章のzone のありかたに従うと、委譲(委任)先がzone (NS)に含まれていないような返答は気持ち悪い。正しいzoneではない。

手順 2:引っ越し元の権威 DNS サーバーのゾーンデータの切り替え

これが可能かどうかが、鍵である。(TTLの短縮などに触れられていない)

   引っ越し元の権威 DNS サーバーのゾーンデータを、NS の指定やグルーレコードの指定なども含め、
      まるごと新しいゾーンデータに切り替えます

手順4に以下のように書いてあるのだが、どういう意味だろう。w 「すべてのキャッシュDNSサーバー群」

すべてのキャッシュDNSサーバー群が引っ越し先の権威DNSサーバーのみを参照するようになるまで、...

1.3. 「新しいデータによる並行運用」は間違い

旧(移転元)サーバーで「新しいデータ」を設定できるのであれば、「並行運用」は必須とは言えない。

設定できることが前提条件になるのであれば、最初に書くべきだ。

大きな問題は移転元でゾーンデータが自由に設定できなかったり、手順が複雑だったりすることだろう。

それにより、移転先の設定だけで済ませようとする手順が多いのではないか。

移転元を古いまま動かし続ける害はGhost Domain Names 脆弱性(2012)としても指摘された。

1.4. lame delegation ではないというのだが

▼正しい委任成立のための三つの条件を(すべて満たす)

 1 親が NS で示したすべての権威 DNS サーバーが、権威を持つ応答を返す
 2 子が NS で示したすべての権威 DNS サーバーが、権威を持つ応答を返す
 3 1と2の権威 DNS サーバーが同じ応答を返す

この条件を守って移転できるか。

この条件が直観に反するケースを含んでいないか。

上記の条件はサーバの視点でしかなく、キャッシュやクライアントから見た場合、

移転作業中も三条件を満足していると考えるのは無理がある。

twitter上では以下の条件が追加されていた。

4)3)がキャッシュを考慮した場合も成立する

キャッシュを考慮した場合というのはかなり無理な要請だ。(常にという意味ではないなら、わからなくもない表現だが)

キャッシュの有効な期間の親からの委譲の不一致をどう考えるか。

新旧両方の委譲が有効だと解釈するのが自然だろう。

1.5. 正しい委譲とはどういうものか

親がNSで示した権威サーバの集合と子が示した権威サーバの集合の不一致をどこまで認めるかについては意見が分かれているようだ。

(通常の状態では)親が委譲した権威サーバの返す返答には自身が含まれているべきであるというのがRFCにあった。ただし、RFCではDNSサーバの移転には触れていない。移転中でもRFCに準拠した状態を維持できるという証明はされていない。移転中は例外を認めることにしてもいいが。

委譲されたはずの権威サーバが自身を含まないNSを返答するという「気持ちの悪い状態」を発生させないためには移転の手順をもう少し複雑にする必要がある。../手順案 -- ToshinoriMaeno 2011-12-01 11:49:51

1.6. 非協力的運用者

NSレコードを利用者が設定できないDNSプロバイダが存在する。

これらのプロバイダは円滑な移転を妨害することを目的に制約していると解釈できる。

-- ToshinoriMaeno 2011-12-01 11:08:57

(委託のための）NSレコードのTTLを短縮できないレジストリがほとんどだ。JPを含む。

1.7. 脆弱性

脆弱なキャッシュサーバを使っている利用者が騙される（乗っ取り）危険性は残っている。

-- ToshinoriMaeno 2013-11-12 00:32:39

MoinQ: DNS/1/コンテンツサーバ/移転/JPRS手順 (last edited 2023-09-10 05:06:42 by ToshinoriMaeno)