要約

  • RFC 8767 は、権威側からの更新を誠実に試みても失敗した場合、再帰リゾルバーが期限切れキャッシュを一時的に返すことを認める。これは公開者の鮮度保証の延長ではなく、リゾルバー側の継続性判断である。
  • 原 TTL、失効後の経過時間、最大保持期限、返却 TTL、DNSSEC の現在状態、更新失敗の種類、対象リゾルバー群、復旧確認を別々に残して初めて、その判断を監査できる。

あるサービスのアドレスが侵害され、運用者は DNS から撤去した。以前の TTL も満了した。それでも一部の利用者には古いアドレスが返る。権威ゾーンの更新漏れとは限らない。再帰リゾルバーが権威サーバーへ到達できず、エラーの代わりに手元の期限切れデータを選んだ可能性がある。

これは説明のための想定であり、実在する障害や製品既定値の主張ではない。可用性を守る処理が、公開者の撤去判断を事実上遅らせる局面を切り出している。

RFC 8767 の Serve Stale は、その局面を無制限には扱わない。TTL の満了後、権威から更新できない場合に、保持済みデータを未失効であるかのように使える条件を示す。古いデータを新しくする規則ではない。

TTL の後には別の権限が始まる

TTL の期間内であれば、キャッシュ再利用の根拠はゾーン公開者が示した通常の鮮度範囲にある。満了すれば、本来は情報源へ照会し直す。そこで更新に失敗し、なお答えを返すなら、根拠は再帰運用者のローカルな継続性ポリシーへ移る。

この切り替わりを記録しないと、「キャッシュが有効だった」という一文が二つの判断を混同する。前半は公開者の TTL、後半はリゾルバーの例外である。後半を決める側には、期間、対象、停止条件を説明する責任がある。

上限も二種類ある。通常の最大キャッシュ TTL は受信した極端に長い値を抑えるもので、RFC 8767 は日から週の単位、推奨値として七日を挙げる。最大 stale タイマーは元の TTL 満了後に始まり、期限切れコピーを候補として何日残すかを決める。文書は設定可能であるべきだとし、一日から三日が多くの停止を吸収し得ると説明するが、世界共通の値にはしていない。

したがって、クライアントが目にする TTL だけでは判断を再現できない。キャッシュ格納時刻、元 TTL、満了時刻、現時点の stale 年齢、最大期限、応答に付けた TTL を保存する必要がある。応答に見える「30 秒」は、多くの場合、何時間も前のデータに下流向けの短い待機を付けた値であり、公開者が三十秒前に確認した証拠ではない。

四つのタイマーは一つの設定ではない

RFC 8767 は単一の実装アルゴリズムを定めない。例示手法に四つの時計があるのは、それぞれ別の失敗を抑えるからだ。

クライアント応答タイマーは、利用者を待たせてから期限切れデータへ切り替えるまでを制限し、例では 1.8 秒を推奨する。クエリ解決タイマーは反復解決全体の作業を区切り、十秒から三十秒程度が説明される。失敗再確認タイマーは応答しない上流への過剰な再試行を避け、例では三十秒を示す。最大 stale タイマーは、障害が続いてもデータを使えなくする最終線である。

管理画面が「Serve Stale: ON」だけなら、実際のトレードオフは見えない。クライアント待ち時間を短くすれば速いが、単に遅い権威より古い答えを優先しやすい。再確認を長くすれば攻撃時の負荷を抑えられるが、復旧検知も遅い。最大期間を長くすれば大規模障害を越えられる一方、廃止済みの状態を保持し続ける。

期限切れデータを返す前には、最近の誠実な更新試行が必要である。常に古い答えを先に出して後で問い合わせるための近道ではない。クライアント向けに答えた後も、解決処理は自身の制限時間まで続けるべきだ。stale 応答は復旧処理の途中経過であり、処理の完了ではない。

更新失敗を一語で片付けない

RFC 8767 では、AA を伴う権威 NOERROR または NXDOMAIN がデータを更新する。以前存在した名前を公開者が正当に削除した場合、リゾルバーは「古い正答の方が便利」という理由で残し続けてはならない。正当な削除と誤設定による NXDOMAIN を一般的に見分ける方法がないからだ。

タイムアウト、経路到達不能、SERVFAIL、REFUSED、不正形式、DNSSEC 検証失敗、lame delegation は、原因も所有者も異なる。RFC 2308 はサーバー失敗や到達不能の記憶を最長五分に制限する。

証跡には、試した各権威エンドポイント、アドレス、トランスポート、時刻、RCODE、AA、検証結果、ネットワークエラー、委任再取得の有無を含めたい。RD、CD、DO、キャッシュキー、正答・NODATA・NXDOMAIN の区別も必要である。履歴と設定が違えば、二台のリゾルバーが同じ質問に異なる答えを返すのはあり得る。

応答 TTL は鮮度の再発行ではない

期限切れレコードを返すとき、応答の TTL はゼロより大きくしなければならず、RFC 8767 は三十秒を推奨する。ゼロは互換性問題を起こしてきた。短すぎる値は下流の再照会を集中させ、障害時の負荷を悪化させる。

しかし、三十秒を付けても元データの年齢は戻らない。フォワーダーがその応答をさらにキャッシュすると、最後のクライアントには真の stale 年齢が見えにくくなる。発信元リゾルバー、最初の格納時刻、直近の更新試行を結び付けなければならない。

RFC 8914 の Extended DNS Error は補助になる。コード 3 は Stale Answer、19 は Stale NXDOMAIN Answer、22 は No Reachable Authority を表す。NOERROR 応答にも追加でき、利用者やログへ事情を伝えられる。

ただし EDE は RCODE 処理を変えず、中継者が転送しないことも、別の EDE を作ることもある。保護された取引や経路がなければ認証情報でもない。コード 3 の観測は、送信者が stale と説明した証拠にとどまり、内部タイマーや照会履歴の独立証明にはならない。

DNSSEC は別の時計で失効する

キャッシュ格納時に検証成功した RRset でも、後で同じ状態とは限らない。RRSIG の開始・終了時刻は TTL とも最大 stale 期間とも独立している。長く残すほど、署名有効期間を越える可能性が高まる。

AD は過去の検証成功ではなく、現在の認証済みデータの意味を示す必要がある。RRSIG 時刻、検証時点、トラストアンカー、CD/DO 条件を残すべきだ。さらに、署名がまだ有効な古いアドレスでも、公開者が既に制御していない機器を指しているかもしれない。暗号学的真正性は、現在の接続先の安全性を保証しない。

否定応答は影響が違う。期限切れ NXDOMAIN は新設名を見えなくし、古い NSEC/NSEC3 は DS や TLSA の更新を遅らせ得る。RFC 8198 の aggressive cache は、通常の有効範囲内にある検証済み否定情報から応答を合成する。Serve Stale は、その通常期限を過ぎ、権威更新にも失敗した後を扱う。

出典