[0] 備忘:bindのzone転送周りの挙動。-[Id of Radiance ver.5]





■ 備忘:bindのzone転送周りの挙動。

例によって今更な話だけど、ちと訳あってbindのzone転送周りについて挙動を検証してみた。とくにSlaveサーバ側の挙動について。

○zone転送のキックはSlaveサーバから。
○いきなりTCP#53をつなぎにいくのではなく、UDPでSOAレコード取得のクエリを投げてSerial値を取得、更新が確認されたらTCPでAXFRを投げる。
○Serial値に更新が無かった場合でもSlave側のzoneファイルの更新日付は上書きされる(RefreshやExpire、TTLなどの時間確認のためと思われる)。なのでSlaveのzoneファイルの時間が更新されていたとしても「zone転送が行われた証拠」にはならない。
○更新確認のキックは、一般的にはSOAレコードのRefresh値毎に行われるとあるが、正確にその時間で発動するわけではないっぽい。おそらく内部で一定時間毎に処理ルーチンが走り、その際に現在時刻が当該zoneのRefresh値+zoneファイルの更新日付を超えていたら処理を開始するものと思われる。
○上記と同じ理由と思うが、Expireを過ぎた上に、SlaveとMaster間の通信が遮断されていた場合でも、わずかながらSlaveから応答が帰ってくる時間帯が存在するようである。
○その前の話として、基本的に、Expireを過ぎつつMasterと通信のできない(zone転送ができない)Slaveは当該zone情報の応答を返さない。古い以上はアテにならんデータは返さないというDNSのポリシーということだろう。
○Expireを超えた状態でbindを再起動した場合、無条件でzone転送要求が行われるっぽい。
○上記のような挙動から、以下のような状況が発生しうる。
 MasterとSlave間の経路で、何らかの理由でTCP#53のみ異常が発生した場合(シンプルなところではFWでTCP#53だけ止めたなど)でも、上記の通り更新確認処理はUDPでのSOAレコードクエリで行われ、Serial値の変更が無い限りzone転送要求は発生しないので、問題が表面化しにくい。SOAレコードの確認でSlaveのzoneファイルの更新時間は上書きされるので一層わかりづらい。
 問題が表面化するのはMaster側で更新が行われてSerial値に変動があってzone転送要求が行われた場合と、何らかの理由でSlaveサーバを停止し、Expireを超える時間を経過してから再起動して強制的にzone転送要求が行われた場合、および手動でzone転送要求を実行した場合になる。

また、Master側がdjbdns(axfrdns)の場合、

○そんなわけで更新確認はUDPのSOAレコードクエリなので、いくらaxfrdnsのログを見ても実際にTCPでzone転送が要求・実行されたログしかわからない。更新確認はtinydns側のログを見る必要がある。

2009-02-04 [技術・作業]