要約

  • DNS NOTIFY 応答はセカンダリが通知を受け取ったことを示すだけで、ゾーン内容の有用な情報を含まない。
  • SOA シリアル比較、IXFR/AXFR、ロード、各提供経路からの権威応答は別々の証拠である。
  • 通知成功を公開完了へ昇格させず、段階ごとのゾーン公開レシートを残す必要がある。

通知キューと提供面は別である

RFC 1996 の NOTIFY は、セカンダリが更新間隔を待たずに変更を知るための割り込みである。対応する応答を受け取れば、マスターはその相手を当該イベントの再送キューから外せる。ここまでが応答の明確な意味だ。

応答は、セカンダリが保持する SOA シリアルも、転送の開始や終了も、新しい世代の有効化も報告しない。仕様は応答に有用な情報がないと明記する。したがって NOTIFY 成功率は、変更の通知経路を測る指標であり、ゾーン提供の完了率ではない。

有効な SOA NOTIFY を受けたセカンダリは、更新タイマーが満了した場合と同様にマスターへ SOA を問い合わせる。シリアルが進んでいれば IXFR または AXFR を開始する。応答はこの後続処理より前に返る。

転送後にも検証点が残る

NOTIFY の回答部は安全でないヒントに限られ、ローカルデータの更新には使えない。RFC 1982 は通常の整数比較とは異なるシリアル演算を定め、半周差の比較を未定義とする。証跡には二つの値と実際の比較結果を残すべきだ。

IXFR は差分を、AXFR は完全なゾーンを運ぶ。RFC 5936 は AXFR を権威サーバー間の整合性維持手段として定義する。しかし転送完了だけでは、reload、各プロセスの切替、anycast 全拠点の収束までは証明できない。

最後は権威サーバーへ直接問い合わせ、期待する SOA と変更対象 RRset を確認する。再帰キャッシュの TTL はこの判断と分離する。

情報源