NSサーバ移転に伴うNSレコードおよびそのTTL変更に関して

tech

TwitterID:@inuwarumonoというのは僕のことです。

Twitterにて@ockeghemさんというか、徳丸浩さんとNSサーバ移転について
教えて頂いたり意見させて頂いたり、やりとりをさせて頂きましたが
僕の言いたかった事が正しく伝えられなかったことと、僕が正しく理解できて
いなかったことなどを、ブログの形にまとめます。

まずは経緯、背景から触れて、次に争点を整理し、検討を加えて最後にまとめます。

経緯

きっかけは徳丸さんのこのツイートでした。

これに対して、NSレコードのTTLが5分というのに意味がない点には完全同意ですが、
僕は徳丸さんの言われた意図を誤認して次のようなお返事をしました。

本当に良く読めよって感じですが、「5分に設定してもすぐ切り替わらないから意味がない」という誤認をしました。
そこで、NSがすぐに切り替わらない理由として、上位NSに設定されたTTLがそこに関わっているという事を説明しようとしました。

その後すぐに

というお返事を頂き、旧権威DNSサーバ上のNSレコードの設定変更が出来ない点を言われていた事に気づいて、話は終了かと思われたのですが

このお返事から、その後のやりとりにつながります。

背景

「DNSの浸透問題」

浸透問題には、いくつか種類があって、JPRS森下さんがInternet Week 2011で
説明された以下のスライドが大変わかりやすいので参照させて頂きます。
http://internet.watch.impress.co.jp/img/iw/docs/494/798/html/s08.jpg.html

いくつかある点のうち

  • DNSキャッシュサーバで、古いNSレコードがキャッシュされているため、旧権威サーバにレコードを問い合わせてしまう問題
  • 古いNSレコードのTTLが、旧権威サーバの設定不備によってリセットされてしまって、DNSキャッシュサーバ上のキャッシュから消えなくなる問題

このあたりが、後の話に関連します。

NSレコード、NSレコードに指定したDNSサーバ名のAレコードの、2重管理問題

ドメイン: example.jp. のNSサーバが、ns1.example.jp., ns2.example.jp. の2つある場合を例に書きます。

上位NS(a.dns.jp.)には、以下のレコードが登録されています。

example.jp.             86400   IN      NS      ns1.example.jp.
example.jp.             86400   IN      NS      ns2.example.jp.
ns1.example.jp.         86400   IN      A       192.168.0.1
ns2.example.jp.         86400   IN      A       192.168.0.2

.jpドメインの場合、TTLは1日になっていて、これは変更できません。


対して、ns1.example.jp., ns2.example.jp. では移転に備えて10分にしてみた、という状況だと仮定します。

example.jp.               600   IN      NS      ns1.example.jp.
example.jp.               600   IN      NS      ns2.example.jp.
ns1.example.jp.           600   IN      A       192.168.0.1
ns2.example.jp.           600   IN      A       192.168.0.2

ここで重要なのは、TTLだけが異なる同じ内容のレコードがある、ということです。


一般のDNSサーバは、どちらのNSレコードをキャッシュするのか？という点が大変問題で
後述のTTLをいくら短くしても〜という事の理由になる部分です。

一般のDNSキャッシュサーバがどちらのNSレコードをキャッシュするかというと
上位NSに記載されているNSレコード、つまり長いTTLのものがキャッシュされている
ケースがあります。

悲しいことに僕は、なぜそうなるかを体系的に説明できず、経験的にそうなっている
ケースを知っているというだけで、僕の主張のとても弱い部分です。

上位NSに聞くと、Authority として応答するし、自NSに聞くと、Answerとして応答する。
キャッシュサーバでどちらが優先されるのか？というあたりの理解に乏しいので
上記についての間違いはご指摘頂けると大変ありがたいです。



さて、長くなりましたがここまでを背景とします。


争点

意見の一致を見れなかった部分は2つあると思います。

浸透問題が不可避という点

浸透問題は複数の問題を内包しているので、どの問題が避けられないと言われていたか、僕は理解できていませんでした。

  • DNSキャッシュサーバで、古いNSレコードがキャッシュされているため、旧権威サーバにレコードを問い合わせてしまう問題

この点、僕は不可避だと思います(後述)

  • 古いNSレコードのTTLが、旧権威サーバの設定不備によってリセットされてしまって、DNSキャッシュサーバ上のキャッシュから消えなくなる問題

これは、設定不備を正せば回避可能で、そこに異論はありません。


http://internet.watch.impress.co.jp/docs/event/iw2011/20111201_494798.html
ここで言われているbindの最新版では、この状況でも問題発生しないように、
キャッシュアルゴリズムが改善されているものと読み取りましたが、具体的な内容はまだ調べていません。
(AUTHORITY SECTIONで返ってくるNSをキャッシュに取り込まない、という実装なんじゃないかと想像)


このあたりが僕の中で整理できたのはこの文章を書き始めてからで、
度重なるメンションで徳丸さんの時間を奪ってしまった事をお詫びします。


TTL短縮で、最終的なNS移転完了を短縮できるか

最終的なNS移転完了というのは、旧権威サーバにクエリが来なくなるまで、です。

旧権威サーバにDNSクエリが届かないようになる、というのは言い換えれば
旧権威サーバに向いたNSレコード(またはそのAレコード)のキャッシュが
世の中のDNSキャッシュサーバから消えるときです。


世の中のDNSキャッシュサーバが、example.jp. のNSレコードをキャッシュするまでのシナリオは以下の通りで

受けた問い合わせに対して、(.からjp.のnsレコードを引いた後に) .jpのNSサーバに、example.jp. の NSレコードを問い合わせる。

その結果は上位NSのTTLを伴って

このように応答されます。

世の中のDNSキャッシュサーバは、権威サーバでなく、上位NSに設定されたNSレコードをキャッシュしている事がある、ということです。
ここで重要なのは、上位NSから委譲を受けているはずの権威サーバの設定にかかわらず、NSレコードがキャッシュされている点です。

つまり、権威サーバ上のNSレコードのTTLをどのように変更しようとも、世の中のDNSキャッシュサーバがそれを
キャッシュしてくれるとは限らないということです。


古いNSレコードをキャッシュしているDNSキャッシュサーバは、example.jp.内のレコード、たとえば www.example.jp. を引く場合

このように、古いNSレコードが残っている限り、example.jp.内のレコードは古いNSサーバに問い合わせる事になります。

検討

旧権威サーバでは、自ゾーンについて、以下のように設定しておく事が推奨されます(浸透問題その2の理由)。

example.jp.   86400 IN NS ns3.example.jp.
example.jp.   86400 IN NS ns4.example.jp.

この設定がされた状態で、DNSキャッシュサーバからAレコードを問い合わせるクエリが来た場合

旧権威サーバは、新権威サーバに問い合わせを流すような事をするかというと、これはしないと思います。


また、

;; ANSWER SECTION:
www.example.jp.       3600    IN      A       192.168.0.100

;; AUTHORITY SECTION:
example.jp.          86400    IN      NS      ns3.example.jp.
example.jp.          86400    IN      NS      ns4.example.jp.

;; ADDITIONAL SECTION:
ns3.example.jp.       3600    IN      A       192.168.0.3
ns4.example.jp.       3600    IN      A       192.168.0.4

このような応答をDNSキャッシュサーバが受け取った時に、これを受け取ったDNSキャッシュサーバは
NSレコードの更新を行うものでしょうか。

DNSキャッシュサーバが、NSレコードの更新を行う事は十分期待できると思いますが

  • この場合において、TTLが短く設定されている事は関連しない
  • DNSキャッシュサーバはこの一台だけではないので、最長1日かかる事には変わりがない

十分減らす事は可能そうだけれど、上位NSが設定した長いTTLによる影響を、
権威サーバ側で短くすることは出来ない、という主張でした。


まとめ

結局僕が言いたかった点は、浸透問題に対してどうということじゃなく、
権威サーバ側でNSレコードのTTLをいじっても無意味です、ということでした。

× TTLを短くすると、早く新権威サーバへの移行が完了する
○ TTLを短くしておいたほうが、より多くのノードに早く新権威サーバを見せる可能性が高まる

ということで、以上になります。

長くてあまりまとまっていないものを読んで頂き、ありがとうございました。

※togetterに時系列で並べてみました
http://togetter.com/li/269765