NSサーバ移転とTTL

徳丸 浩 @ockeghem

http://t.co/tIIZRBEJのレンタルDNSサーバーではNSレコードは変更できない（http://t.co/OitfUqKkなど固定）ので、NSレコードのTTLが5分というのは本当に意味ない、と思います

犬さん @inu3_

@ockeghem NSレコードは、自NSと上位NSの両方に設定があります。双方でTTLが異なる事はよくある事で、例えばhttp://t.co/NOUK8ng0は、*.gtld-servers.net. に聞くと2日、http://t.co/jSRIzSjz.に聞くと1日です。

徳丸 浩 @ockeghem

@inuwarumono それは承知しておりますが、自NSのNSレコードがいじれないのは引っ越しの時に困るなぁと思います。その前提での話です

犬さん @inu3_

@ockeghem (続き;以下は推測を含みます)。NSレコードは上位NSが応答したNSレコードがキャッシュされる事が多く、自ゾーンのNSレコードのTTLを変更しても、効果がない場合が多くあります。よって、.comなら2日、.jpなら1日と考えるべき、と思っています。

犬さん @inu3_

@ockeghem 前提をよく読まずに失礼しました。NSレコードに設定したサーバを移転するケースですね。

徳丸 浩 @ockeghem

@inuwarumono いえ、twitterですのでこちらも前提を明記しておりませんでした。ありがとうございます

徳丸 浩 @ockeghem

どうですかね。それだと「浸透問題は不可避の現象」と読めますが… RT @inuwarumono: @ockeghem (続き;以下は推測を含みます)。…自ゾーンのNSレコードのTTLを変更しても、効果がない場合が多くあります。よって、.comなら2日、.jpなら1日と考えるべき…

徳丸 浩 @ockeghem

@inuwarumono まぁ、途中はともかく、http://t.co/9NzuYeviがNSレコードのTTLを短くしているのは無意味、という点では同意見ですね

犬さん @inu3_

@ockeghem 一般のDNSキャッシュサーバがキャッシュしているNSレコードが、自NSのNSレコードか、上位NSのNSレコードか、2通りあって、上位NSのNSレコードがキャッシュされているケースがある、というのが僕の推測部分です。(続きます)

犬さん @inu3_

@ockeghem (続き) 上位NSのNSレコードがキャッシュされているケースがあるという推測が正しければ、長いTTLを待たないと更新完了にならない場合がある、という意味で書いたんですが、「浸透問題が不可避」というのがあまり理解できなくて、説明になってなかったらすみません。

犬さん @inu3_

@ockeghem なんだか何度もすいません、自NSでNSレコードのTTLを短くすることが無意味なのは全く同意見です。

徳丸 浩 @ockeghem

@inuwarumono 論点が噛み合ってないですね。上位NSのTTLは変更できないのでキャッシュが残ることはありますが、その場合でも旧のDNS権威サーバーから新DNS権威サーバーに委譲することで、切り替えにかかる時間を短くでき、その場合NSのTTL短縮は意味があると思います

犬さん @inu3_

@ockeghem 旧権威サーバで、example.jp 300 IN NS 新権威サーバ、とするということでしょうか。その場合でも、example.jp 1d IN NS 旧権威サーバ、のキャッシュが最長1日消えないせいで旧権威サーバにクエリが出ることは防げないと思います。

徳丸 浩 @ockeghem

@inuwarumono いったん旧権威サーバーにクエリされ、そこから新権威サーバーに委譲されているので、結果的に新権威サーバーが参照されると思います

犬さん @inu3_

@ockeghem ちなみに、NSレコード以外にも、NSレコードに指定した名前のAレコードもNSレコードと同様に上位NSに書かれているので、この点の考慮も重要です。やっぱり論点がズレているでしょうか。僕はNS変更完了を、旧権威サーバにクエリが出ない状態、と捉えています。

徳丸 浩 @ockeghem

@inuwarumono 「NS変更完了を、旧権威サーバにクエリが出ない状態」と考えるのであればその通りかと思います。

犬さん @inu3_

@ockeghem なるほど、僕はその動作について誤解していました。旧権威サーバにAレコードを問い合わせた場合、example.jp. IN NS 新権威サーバと設定していても、Aを答えてしまうと思っていました。新権威サーバのNSを答えるだけになる、ということですね。

徳丸 浩 @ockeghem

@inuwarumono 旧権威サーバーを明示的に指定して問い合わせたら旧のAレコードが返りますが、通常はまず権威サーバーを確認するので、その際に、委譲された新権威サーバーが返り、その新権威サーバーからAレコードを参照する流れになると思います

犬さん @inu3_

@ockeghem この度は丁寧にご回答いただきありがとうございました。おかげで理解が深まりました。

犬さん @inu3_

@ockeghem すみません、またわからなくなりました。「まず権威サーバーを確認するので」の部分で、上位NSの長いTTLを持ったDNSキャッシュサーバは、改めてNSレコードを確認せず、旧権威サーバにAを問い合わせてしまう、という動作はあってますか？

徳丸 浩 @ockeghem

@inuwarumono 上位サーバからNSを調べようとするが旧権威サーバーがキャッシュに残っている→旧権威サーバーのNSのキャッシュはタイムアウト→旧権威サーバーにNSを問い合わせる→新権威サーバーに委譲されている→新権威サーバーを参照する…という流れだと思います

犬さん @inu3_

@ockeghem 「旧権威サーバのNSのキャッシュはタイムアウト」の部分ですが、これが運の悪いDNSキャッシュサーバだと.jpドメインなら最長1日かかるので、NS移転開始から完了までは、上位NSが設定した長いTTLが過ぎるまで移転完了にはならない、というはいかがですか？

徳丸 浩 @ockeghem

@inuwarumono 旧の権威サーバーを撤去できない、という意味では、その通りだと思います

犬さん @inu3_

@ockeghem ここらへんで元の話に戻りますが、上位NSの長いTTLを経るまでは、旧権威サーバは自ゾーン内のAを応答するケースがありますよね？つまり、旧権威サーバで自ゾーンのNSレコードのTTLをどんだけいじっても、移転完了を短縮することにはならないのでは？

徳丸 浩 @ockeghem

@inuwarumono 旧権威サーバーを明示的に指定(dig @旧権威サーバー …など)しない限りそうならないし、そうでないと委譲の意味がないと思います