移行時のDNS TTLを選ぶ：前提条件を記録する

数値より先に期待の範囲を決める

許可されたレコードと型、一時設定の理由、DNS事業者、モード、根拠の担当を明記します。現在値、候補値、継承した既定値を分け、各欄を日付付き資料で変更可能・固定・不明に分類します。表示されたTTLが編集可能な個別レコード設定とは限りません。

本シートは切り替え計画より狭い判断を扱います。公開順序、運用の確認点、差し戻しは別計画へ、メール依存は専用の確認へ渡します。時間を短く見せるために無関係なレコードや委任を変えません。

空欄のTTL判断シートから始める

表紙：目的・範囲____、事業者・モード・プランの資料と日付____、担当____、予定枠・時間帯____、保護する依存____、別の切り替え担当____。認証情報や非公開ゾーン値でなく承認済み資料を参照し、レコードまたは期待ごとに繰り返します。

空欄や不明は限界の明示です。公開予定時刻も式も、実行の証拠ではありません。後日別途許可された観測には独自の資料、時刻、範囲を記録します。

期間と事業者の設定権限を分ける

RFC 8767の4節はTTLを、再び情報源へ照会するまでの秒単位の期間として説明し、ゼロは進行中の処理だけに限定します。権威側から更新できない場合は期限切れデータの条件付き利用も認めます。2020年3月の文書は、TTLを無条件の鮮度期限にする根拠ではなく、全リゾルバーがserve-staleを使うとも述べません。[1]

2026年4月16日更新のCloudflare資料では、プロキシ付きレコードのAutoは300秒で固定、DNSのみはプランに応じた選択肢、ネームサーバーTTLは別機能です。ローカルキャッシュによる表示の遅れも説明します。実モードと現行選択肢を確認し、Autoの意味や編集可否を全事業者共通にしません。[2]

存在しない応答は別の分岐で扱う

RFC 2308の3〜5節では、対象範囲の負の応答の期間はSOAのTTLとSOA.MINIMUMの小さい方から決まります。NXDOMAINのキーは名前・クラス、NODATAは名前・型・クラスと区別します。タイムアウト、別のエラー、空応答を自動的にどちらかへ分類しません。担当者に適用根拠を求め、本稿では問い合わせません。[3]

1998年3月の文書は、以後のTTL省略レコードに使うマスターファイルの既定値$TTLと、SOA.MINIMUMも区別します。A・AAAAの正の応答候補や$TTLを負のキャッシュ根拠の代用にしません。歴史的署名の詳細やリゾルバー推奨数値は採用せず、事業者が調整欄を公開するとも仮定しません。[3]

架空のBirch Lantern Migration：事前期間を修正する

T1の短縮公開予定は08:00、別の切り替えは09:30です。7200秒＝2時間、単純モデルは08:00＋2時間＝10:00。予定の事前期間は90分で30分不足するため、修正と判断します。10:00でも全キャッシュの期限やサービス準備は証明できず、候補600秒は保存済みの旧7200秒をさかのぼって置換しません。

T3ではmin(1800,900)＝900秒＝15分。ある架空リゾルバーが対象NXDOMAINを14:05に保存した場合、通常の負TTLモデルは14:20へ達します。利用予定14:10は保存から5分で10分不足。T1の600秒とは独立で、世界共通の保存時刻や実際の不存在ではありません。NODATAや他のエラーは別分類のままです。

変更可能だが事前期間修正1＋固定モード編集却下1＋独立した負の例1＝3行です。全員共通TTL、公開、キャッシュ消去、移動先廃止はありません。架空担当Miraは別途許可された切り替え受入根拠の後にT1を再検討しますが、その根拠は本稿にありません。

条件付きの時間的な期待を書く

短い候補は将来のキャッシュ応答の通常期間を減らし得ますが、キャッシュと更新問い合わせの比較が必要です。移動先障害、委任、ローカルキャッシュ、更新失敗を解決するものではありません。旧TTLと公開予定を将来の候補値から分けます。[2]

実際の以前の更新や条件付きserve-stale方針で不明な点を示します。単純モデルは短すぎる事前期間を見つける補助で、全世界の最終期限、実効的な最大期限超過期間、サービス受入れではありません。60秒・300秒や24〜48時間という自動的な手順は導きません。[1]

次の根拠と後日の確認担当を決める

対応する候補と理由、変更可否の根拠、旧応答の前提、負の分岐、未解決の問い、条件付き時間説明を渡します。別計画の受入後、一時TTLを誰がどの条件で確認するかも明記します。長い値へ戻す場合も別の期待が生じます。本シートは実行やサービス廃止を許可しません。