要約

  • RFC 8767が許すのは、誠実な更新試行で利用可能な権威データを得られなかった後の、時間を限定した代替応答である。TTLの意味は消えない。
  • 元のTTL、最大stale期間、クライアントの待ち時間、返却TTL、DNSSEC署名期間、EDE、再試行間隔はそれぞれ別の事実を示す。
  • David C. LawrenceはRFC 8767の3人の著者の一人である。共同執筆は、ゾーン、リゾルバ、実装、ICANNの判断への運用権限を意味しない。

リゾルバの時計がゼロを指した。手元には直前まで有効だったRRsetがあるが、権威サーバーから新しい応答は来ない。アプリケーションは待っている。ここで古い値を返せば処理は続き、返さなければSERVFAILになる可能性が高い。

問題は、返せたことと正しかったことが同じ指標に見えやすい点にある。利用者には通常のアドレスが届く一方、ゾーン所有者がすでに値を変えた可能性は残る。可用性の成功だけでは、どちらの権威に従ったか分からない。

David C. Lawrence、Warren Kumari、Puneet Soodが執筆し、2020年3月に公開されたRFC 8767は、この例外を状態遷移として扱う。古い値は一時的な橋になれる。しかし橋が目的地の所有者になるわけではない。

保存状態と回答可能状態を分ける

RFC 1035はTTLを、リソースレコードをキャッシュできる期間として定める。RFC 2181は、その期限を越えて現在の情報として扱わないという境界を明確にする。TTLは単なるメモリ整理の都合ではなく、公開者がキャッシュに渡した時間条件である。

実装は期限後もバイト列を保持できる。障害解析、差分確認、限定的な復旧に役立つからだ。ただし、保持していることとクライアントに返せることは別の状態でなければならない。RFC 8767が追加するのは後者の条件である。

受信時のTTLがゼロだったデータは対象外となる。公開者はキャッシュ再利用を最初から認めていない。リゾルバ側が後からstale期間を付与すれば、元の指示を上書きすることになる。

したがって証拠は障害前に始まる。名前、型、クラス、応答元、内容のハッシュ、受信TTL、格納時刻、通常の満了時刻、DNSSEC状態が必要だ。「最後に良かった答え」だけでは、対象も年齢も選定理由も確定しない。

先に権威経路を試す

RFC 8767は、直近の誠実な更新努力を求める。リゾルバは権威経路へ問い合わせ、クライアント応答の待ち時間内に利用可能な結果を探す。失敗または時間切れの後で初めて、期限切れキャッシュを利用できる。ごく最近の問い合わせが上流障害を確認済みなら、後続の問い合わせは毎回同じ待ち時間を繰り返さなくてもよい。

この順序は、ゾーン所有者が値を変更する力を守る。緊急のアドレス変更、サービス停止、証明書に関係するDNS更新は、権威サービスが利用できるなら速やかに見えるべきだ。古い方が速いという理由で常に先に返せば、継続性が無断の公開延長に変わる。

「誠実」は監査できなければならない。問い合わせ先、トランスポート、開始と終了、応答または失敗分類、DNSSEC結果、再利用した直近障害の時刻を残す。タイムアウト、SERVFAIL、権威NXDOMAIN、署名検証失敗は同じ故障ではない。

期限切れ応答を返したことも復旧ではない。クライアントは処理を続けられたが、情報源は戻っていない。RFCは更新試行の継続を求める。新しい権威応答を取得し、評価し、現在のキャッシュとして格納した時点が復旧である。

一つの応答に六つの時間がある

第一は権威側の元TTLであり、通常の鮮度を決める。RFC 8767は、stale計算に使う受信TTLを7日程度で上限設定する案も示す。極端に大きなTTLから無期限の例外を作らないためだ。

第二はリゾルバが決める最大stale期間である。設定可能であるべきで、推奨値として1日から3日が挙げられる。この期限を越えれば、保存されていても代替応答には使えない。

第三はクライアントの待ち時間で、通常は秒単位となる。短くすれば応答は速いが、単に遅いだけの権威応答を退ける回数も増える。

第四はstale応答に付ける返却TTLである。正の値が必須で、30秒が推奨される。下流キャッシュの再利用を短く制限する値であり、元データを若返らせる値ではない。

第五はDNSSEC署名の開始・終了時刻である。RRsetのTTLが切れても署名が有効な場合がある一方、ローカルのstale期限より先に署名が失効する場合もある。キャッシュ設定で暗号学的な時刻は延長できない。

第六は更新再試行とバックオフである。速すぎれば障害中の権威系に負荷を加え、遅すぎれば古い値が実用上の答えであり続ける。記録では六つを別々に示す必要がある。

DNSSECは「現在」を署名し続ける装置ではない

RFC 4035に従う検証リゾルバは、信頼連鎖と署名の時間範囲を確認する。期限切れRRsetでも署名が有効ならSecureになり得る。それは、ある時点で所有者の鍵が署名した証拠であって、現在も同じ値を望んでいる証拠ではない。

RFC 8767は、古くなるほど検証失敗が起きやすいと警告する。また、攻撃者が権威サービスを到達不能に保つことで、以前の値の利用を長引かせる危険を示す。署名を偽造しなくても、「過去に認証された」と「現在の意思である」の差を利用できる。

許容できるかは利用目的で変わる。一時的にウェブページへ到達することと、DNSチャレンジを根拠に証明書を発行することは同じではない。RFCは認証局に対し、その検証でstaleリゾルバへ依存しないよう注意を促す。

否定応答も古くなる。古い正応答は廃止先へ通信を送り続け、古いNXDOMAINは新しく作られた名前を見えなくする。RFC 8914がStale NXDOMAIN Answerを別の診断にしたのは、不在も鮮度を要する主張だからである。

EDEは例外を知らせるが正当化しない

Lawrenceが共同執筆したRFC 8914はExtended DNS Errorを定める。コード3はStale Answer、コード19はStale NXDOMAIN Answerである。対応するクライアントや運用者は、通常の現行応答と区別できる。

EDEだけではRCODEは変わらない。RRsetを認証せず、上流障害の理由を証明せず、署名を延長せず、アプリケーションが読んだことも保証しない。多くの利用者は例外を知らないまま値を使う。

だからEDEは目撃記録として有用である。年齢や理由別に数え、高リスク処理で拒否する手掛かりになる。ただし、リゾルバ自身の判断記録を置き換えない。

コード3の件数は、キャッシュ対象、更新試行、適格性、返却TTL、DNSSEC、後の復旧と結合して初めて意味を持つ。

実装の既定値は標準の命令ではない

RFC 8767はBIND 9.7.0向けの初期パッチ、2011年からのAkamaiでの運用報告、その後のBIND 9.12以降、Unbound、Knot Resolverでの対応を記す。運用経験が回復力を改善したという集団的な履歴である。

現在のUnbound文書は、1.23.0からRFC 8767の動作を既定にしたと説明する。クライアントが1.8秒待った後、またはSERVFAILの代わりに期限切れ値を返し、既定の最大期間を1日、返却TTLを30秒とし、その後も解決を続ける。

これらは現行の一実装の選択で、IETFの一律要件ではない。設定変更や版の更新で変わり、他の製品を説明しない。

実際の証明には、ソフトウェア、版、実効設定、問い合わせごとの状態遷移、送信した応答が要る。権威が正常な場合、無応答、SERVFAIL、DNSSEC失敗、期限前後の復旧、値の変更、TTLゼロを制御試験する。文書は可能な挙動を示し、実行記録が発生した挙動を示す。

Lawrenceの役割は長い参加の記録である

IETF DatatrackerはDavid C. Lawrenceを「tale」として掲載し、RFC 3425、7871、8767、8914を挙げる。確認時点ではAdaptive DNS Discoveryの共同議長、ICANN理事会へのIETFリエゾン、DNSやインターネット関連のレビュアーである。

ICANNの現行理事会ページは、David Lawrenceが2024年11月14日からIETFの非投票リエゾンであるとする。略歴にはRPIとUsenet、UUNET、ISCでのBIND再実装、Nominum、Akamaiでの13年、2010年のDNSSEC Root Key Trusted Community Representative、DNS-OARCとCVFiberの理事経験がある。

これはDNS実装、標準化、組織間連絡への参加を示すが、単独発明や運用支配を示さない。RFC 8767には3人の著者がおり、広い実装経験とIETFの合意がある。ICANN理事会でも投票権を持たない。

人名は貢献を帰属させるが、配備権限を移さない。キャッシュも機能を支えるが、名前の権威を移さない。

復旧まで閉じた受領記録を作る

最初に、名前、型、クラス、応答元、元TTL、格納・満了時刻、内容ハッシュ、DNSSEC状態を保存する。次に、直近更新の対象、トランスポート、時間、応答・失敗分類、直近故障の再利用を記す。

判断には最大期間、算出した期限、応答時の年齢、待ち時間、返却TTL、EDE、例外ポリシー、次回試行が並ぶ。高リスク利用者に適用しないなら、その除外も必要だ。

最後は新しい権威応答、検証結果、新しい内容ハッシュ、格納時刻、stale状態の終了、利用者への影響で閉じる。新しい値が異なる場合、中断中に古い値を返した履歴を上書きしてはならない。

これは、キャッシュの門番ではなく判断の台帳を守る設計である。継続性を確保しても権威は移らない。由来、年齢、期限、復帰が証明できる間だけ、古い応答は正当な例外になる。

出典