要約

  • RFC 9664 では、要求側が示す時間は希望値であり、成功応答に含まれる LEASE と KEY-LEASE が権威サーバーの実際の付与時間になる。
  • リース満了は権威側の古い公開を止めるが、サービス稼働、権威群の収束、残存 TTL を持つキャッシュの消去までは証明しない。

説明のため、端末がサービスレコードを 30 分間登録したいと要求したとする。DNS UPDATE の前提条件と認証は通り、サーバーは成功を返す。ただし応答の Update Lease は 4 時間だった。20 分後に端末が停止し、削除も更新も送らなかった。

このとき、残り時間の権威応答はリース契約に沿っていても、接続先のサービスはすでに存在しない。これは実際の障害事例でも、製品の既定値を示す数字でもない。RFC 9664 が、要求より短い、同じ、または長い時間をサーバーに付与させ得ることを示す仮定である。

更新を受理する権限と、時間を与える権限

Update Lease は DNS UPDATE を置き換えない。RFC 2136 の通常のメッセージに、EDNS(0) の OPT 擬似 RR として入る。Zone、Prerequisite、Update、Additional Data の各セクションは残り、現在のゾーン状態に対する前提条件がすべて成立したときだけ変更全体が原子的に受理される。

ここで判定されるのは、ある主体がこの状態に対してこの変更を行えるかどうかである。成功応答のリースが決めるのは、更新が来ない場合にサーバーがいつまで RR を公開するかである。レコードが示すサービスの稼働は、別の観測で確かめなければならない。

TSIG や SIG(0) はトランザクションと署名主体を認証できる。更新ポリシーは鍵の権限を名前や RR タイプに限定できる。しかし、アプリケーションプロセス、待受ポート、経路、利用者の処理結果までは検査しない。認証済みの登録であることと、正常なサービスであることは別だ。

証拠には DNS メッセージの各セクション、TSIG 鍵名または SIG(0) の識別、ポリシー判定、オプション長、希望値、RCODE、返却値を残す。「リース成功」という一行では、誰がどの時間を与えたかを失う。

4 バイトと 8 バイトが分けるもの

4 バイト形式は 32 ビットの LEASE 一つを持ち、Update セクション内の KEY を含む全 RR に適用される。8 バイト形式では KEY-LEASE が加わり、通常 RR と KEY RR の時間を別々に扱う。

RFC 9665 の Service Registration Protocol では、この差が名前の継続性を支える。サービス発見用 RR が期限切れになった後も KEY が残り、同じ暗号鍵の所有者のために名前を予約できる。残るのは名前の主張であって、サービスの存在ではない。

旧実装との互換性により、この二つは一つに戻ることがある。4 バイト要求を受けたサーバーは同じ値を両方に使う。要求側が 8 バイトを送っても 4 バイト応答を受けたなら、返された一値を両方に適用する必要がある。「サービスは短く、名前は長く」という設計意図が実現したかは応答そのものを見なければ分からない。

明示的に削除された RR は恒久的に削除される。リースは削除を一時停止に変える仕組みではない。

返答された時間から更新を組み立てる

機能を実装する権威サーバーは、Update Lease 付き更新を成功させたなら、付与時間を同じオプションで返す。要求側はその 80% に 0% から 5% のランダム値を加えた時点で更新する。大量の端末が一斉に送信するのを避け、満了まで 15% から 20% の再送余地を残す考え方だ。

計算済みのタイマーは更新成功の証拠ではない。選ばれた乱数、予定時刻、送信、認証済み応答、新しい付与値が必要になる。

成功応答に Update Lease がなければ、サーバーが未対応であることを示す。RFC は要求側に、要求値が返ったものとして更新を続けるよう勧める。これは互換動作であり、サーバーが期限切れ RR を自動で止める証明ではない。運用状態は「クライアント更新継続、サーバー満了処理は未確認」と記録すべきだ。

Registration と Refresh も区別される。前者は存在しないと考えられる情報を加え、後者は既存状態を変えずに延長する。再起動などでサーバーが状態を失っていれば、Refresh が RR を再登録する場合がある。このときゾーン内容が変わるので serial は更新される。内容が変わらない単なる延長では serial を増やしてはならない。

権威側で消えても、キャッシュには残る

更新なしにリースが満了すると、権威サーバーは RR を応答してはならない。データベースから削除してもよいが、必須ではない。問い合わせ結果と保存状態は別々に確認する必要がある。

TTL は異なる時計である。満了直前に答えを得た再帰リゾルバーは、残り TTL が尽きるまで再利用できる。権威サーバーにはそのコピーを回収する手段がない。一方、TTL を短くしても、権威サーバーが 4 時間保持する登録は早く終わらない。

調査では、付与満了、要求側の更新と再送、署名・ジャーナル・セカンダリへの反映、観測した TTL を分ける。登録を受けたサーバーが hidden primary なら、その内部表が正しくても公開権威群の応答までは証明しない。

そして DNS の外に、実サービスの確認が要る。対象アドレスとポートへ接続し、意味のあるプロトコル処理を完了できて初めて可用性の証拠になる。

一律の時間ではなく、見えるローカル方針

長すぎるリースは期限なしに近づき、短すぎるリースは更新負荷と早過ぎる消失を招く。RFC 9664 は既定上限として通常 LEASE 24 時間、KEY-LEASE 7 日を推奨する。既定下限を設けることを求め、30 秒以上を推奨しつつ、多くの場合は 1 時間のような長い値が望ましいとする。運用者は変更できる。

これらは要求側の権利でも、全環境共通の目標でもない。サーバーのローカル方針を版管理し、観測できることが重要だ。鍵の権限も狭くする。リースは不正に書かれた RR の残存時間を区切れても、ゾーン全体を変更できる強すぎる鍵を安全にはしない。

出典