サーバーの切り替え前日に、レコードのTTLを300秒へ下げておく。当日の作業を9時に始めれば、9時5分には全員が新しい側を見ている。そういう段取り表を作ったことがあるなら、この記事の対象です。
この段取りは、半分は当たります。TTLを下げておくことに意味はあります。ただし「300秒後に切り替わる」という読み方は、仕様が書いていることとずれています。TTLが決めているのは切り替わる時刻ではなく、古い答えが返り得る期間の上限です。上限であるという一語の差が、当日に何を監視するかを変えます。
筆者も当初は、TTLを短くすれば切り替え時間が短くなる、という一方向の話だと考えていました。しかし関連する文書を読むと、TTLが効かない経路が複数あり、しかもその向きが互いに逆でした。長くしても効かない経路と、短くしても効かない経路が、別々に規定されています。
この記事では、RFC 8767（2020年3月発行、Standards Track）とRFC 9520（2023年12月発行、Standards Track）の本文を突き合わせて、その経路を分けます。両文書はいずれも2026年10月30日に取得し、HTTP 200で本文を確認しました。扱わないのは、レジストラやホスティング各社の操作手順と、特定のリゾルバ（問い合わせを代行して答えを覚えておく側のサーバー）が実際に設定している値です。後者は各社の文書を別途当てる対象で、RFCは推奨値を示すだけで実装値を決めません。
30秒で要点
- TTLの定義はRFC 8767で改訂され、「そのレコードをキャッシュしてよい期間であり、その後は情報源に再度問い合わせなければならない」という形になった
- 権威サーバーが返したTTLは、受け取る側の上限設定で切り詰められる。RFC 8767が推奨する上限は604,800秒（7日）である
- TTLが切れても、権威サーバーから更新できなかった場合は期限切れのレコードを返してよい。保持期間の推奨は1〜3日で、返すときのTTLは30秒が推奨値である
- 解決に失敗したという結果そのものもキャッシュされる。RFC 9520は最低1秒のキャッシュを必須とし、5分を超えてはならないと定める
- 同じ「5分」が別々の規定として二度出てくる。どちらの5分かを区別しないと、待ち時間の見積もりが崩れる
TTLは「キャッシュしてよい期間」であって「生きている期間」ではない
RFC 8767は、TTLの定義そのものを書き換えています。改訂後の定義では、TTLは「そのリソースレコードをキャッシュしてよい（MAY）期間であり、その後は情報源に再度問い合わせなければならない（MUST）」とされます。
旧来の文言と比べると、どこが変わったのかが分かります。RFC 8767は、以前の定義が「キャッシュしてよい期間であり、その後は情報源に再度問い合わせるべき（should）」「破棄されるべき（should）期間」という形だったと示しています。そして、その文書がRFC 2119の用語法（MUST・SHOULD・MAYの意味を定めた取り決め）より前に書かれたため、「may」や「should」の解釈が緩かったと自ら説明しています。
ここは「昔の定義が間違っていた」という話ではありません。同じ内容を、誰が何を守るべきかが読み取れる用語で言い直したということです。言い直した結果として見えるのは、TTLの主語が「レコードの寿命」ではなく「キャッシュしてよい上限」だという点です。
この読み方は新しく現れたものでもありません。RFC 8767は背景の説明として、RFC 2181の一節を「TTLは生存期間の上限を定めるものであって、義務づけられた生存期間ではない」と引用しています。ただし今回開いたのはRFC 8767とRFC 9520の2文書だけで、RFC 2181そのものは読んでいません。ここは「RFC 8767がそう引用している」という形までを根拠にします。
なぜ秒数を見ると「待てば終わる」と読めてしまうのか
定義を知っても、最初は残り時間として読みます。この誤読が強いのには理由があります。
ひとつは、単位が秒だからです。300という数字が秒で与えられると、人はそれを締め切りまでの残り時間として扱います。「上限」という量は、日常ではあまり秒で表されません。賞味期限や待ち時間のように、秒で示される数字はたいてい「それだけ待てば終わる」側の量です。
もうひとつは、自分の手元では実際に切り替わって見えることです。作業後に自分の端末で確認すれば、ほどなく新しい答えが返ってきます。この観測は「切り替わった」という結論を支持してしまいますが、実際に確認できたのは自分が使っているリゾルバ1台の状態だけです。手元の成功体験が、全体の状態の証拠として扱われます。
三つめは、「浸透」という比喩です。水が広がるような像を結ぶので、始まりと終わりのある一つの過程として理解されます。ところが古い答えが返り続ける理由は、このあと見るように複数あり、それぞれ対処が違います。一語でまとめた瞬間に、どの経路なのかを問う習慣が消えます。
この語が誤用だと評価するつもりはありません。今回参照した2文書はこの語を使っておらず、否定もしていないので、仕様を根拠に言葉を否定することはできません。言えるのは機能の話だけです。この語では、以下の経路のどれが起きているのかを区別できません。
長くしても効かない方向：受け取る側の上限で切り詰められる
ひとつめの経路は、TTLを長く設定したときに現れます。
RFC 8767は、改訂後のTTL定義のなかで「値は日から週の規模で上限を設けるべき（SHOULD）であり、推奨する上限は604,800秒（7日）である」としています。この上限は、権威サーバー（そのドメインの正式な答えを返す側）が返してきたTTLを、受け取る側が切り詰めるための設定です。同文書は、多くのリゾルバに存在する最大キャッシュTTLを「権威サーバーから受け取ったTTLの値に対する切り詰め（clamp）」と説明し、7日という値は現代の主要なリゾルバの実務を反映したものだと述べています。
つまり、権威側で1か月のTTLを設定しても、受け取る側がそれを尊重する義務はありません。RFC 2181が許す31ビットの範囲（年数に換算すれば68年分）に対して、実務上の上限が別に置かれている形です。
この経路は、切り替え時間の問題とは向きが逆です。 困るのは「長く覚えておいてほしいのに、短く切られる」場面であって、「短くしたのに効かない」場面ではありません。同じTTLという語をめぐる制約ですが、混ぜて読むと話が通らなくなります。切り替えの段取りで効いてくるのは、次の2つの経路です。
短くしても効かない方向：更新できないときは期限切れの答えを返してよい
ふたつめの経路が、RFC 8767の主題です。改訂後のTTL定義には、こう書かれています。TTLが切れたときに権威サーバーから更新できなかった場合、そのレコードは期限切れでないものとして使ってよい（MAY）。
これが serve-stale と呼ばれる動作です。どれだけ保持してよいかについて、同文書は「期限切れになったレコードをキャッシュに保ち続ける長さ」を定める値を置き、推奨を1日から3日のあいだとしています。さらに、期限切れのレコードを応答に載せるときは、TTLを0より大きい値（推奨は30秒）に設定しなければならない（MUST）と定めています。
ここで条件を落とさないことが重要です。この動作が働くのは、権威サーバーから更新できなかったときです。 移転先の権威サーバーが正常に答えている状況で、無条件に古い答えが返り続けるという規定ではありません。また同文書は、示している手順を「例として挙げる方法」であり「形式的なアルゴリズムを意図的に与えていない」と明言しています。serve-stale の処理は各実装のローカルな動作だとも書かれています。したがって「最大3日は古い答えが返る」と条件抜きで述べることはできません。
では、どういうときに「更新できなかった」と判定されるのか。ここに、切り替え作業と直接関わる規定があります。RFC 8767は、権威サーバーからの応答のうち、応答コードが0（NoError）または3（NXDomain）で、かつAAビット（その答えが権威あるものだと示す印）が立っているものだけを、データが更新されたと見なさなければならない（MUST）としています。そしてそれ以外の応答コードは更新の失敗として扱うべき（SHOULD）であり、以前の状態をそのまま残すとしています。
この一文から読めることは具体的です。切り替えの当日に、権威サーバーが一度でもSERVFAILのような応答を返したなら、受け取った側では古い状態が据え置かれる条件が成立します。何分遅れるかは実装によるので書けませんが、遅れる条件がどこで生まれるかは特定できます。切り替え当日に監視する対象が、ここで1つ決まります。
失敗したという結果も、それ自体がキャッシュされる
三つめの経路は、RFC 9520が扱っています。こちらは成功した答えではなく、失敗した結果のキャッシュについての文書です。
RFC 9520は、解決の失敗を「問い合わせの名前・タイプ・クラスの組に対して、利用できるどのサーバーも有用な応答データを返さない状態」と定義します。有用な応答とは、求められたデータか、下位のゾーンへの委任の案内か、その名前にデータが存在しないという明示のいずれかを与えるものです。この定義のもとでは、SERVFAILとタイムアウトは同じ「解決失敗」として扱われ、両者に別々のキャッシュ時間は定められていません。
そのうえで同文書は、リゾルバは解決失敗のためのキャッシュを実装しなければならない（MUST）と定めます。キャッシュする時間は最低1秒が必須で、5分を超えてはならない（MUST NOT）。キャッシュが有効なあいだ、リゾルバは対応する外向きの問い合わせを送ってはならない（MUST NOT）とされています。最小のキャッシュ時間は運用者が設定できるべき（SHOULD）だとも書かれています。
ここでも上限と実際の待ち時間を混ぜないことが必要です。5分は上限であって、常に5分待たされるという規定ではありません。 最小値は1秒です。失敗が続く場合については、指数的または線形のバックオフ（やり直しの間隔を徐々に延ばす方式）でキャッシュ時間を延ばすべき（SHOULD）だとされ、例として初期値を5秒にして失敗のたびに延ばす形が挙げられています。この5秒は「例えば」として示された値であり、規定値ではありません。
この文書が変えたのは必須かどうかの位置です。RFC 9520は、それまで任意だった解決失敗のキャッシュを必須にするためにRFC 2308を更新すると述べています。あわせてRFC 4035とRFC 4697も更新する旨が書かれていますが、DNSSEC（答えが偽造されていないかを検証する仕組み）の検証失敗に関する規定の本文までは今回読んでいません。
用語には注意が必要です。「ネガティブキャッシュ」という語は、RFC 2308の文脈では存在しない名前（NXDOMAIN）やデータなし（NODATA）の応答を覚えておくことを指します。RFC 9520が必須化したのは、サーバーに到達できない・SERVFAILが返るといった解決の失敗の方です。似た語で一緒に語ると、どちらの話をしているのか分からなくなります。
再試行の回数にも上限があります。同文書は、リゾルバは同じサーバーアドレスへ同じ経路で同じ問い合わせを2回より多く再試行してはならない（MUST NOT）としています。これはタイムアウト時の再試行の規定で、キャッシュ時間とは別の条文です。
同じ「5分」が、別の規定として二度出てくる
ここまでで、5分という数字が2回登場しました。混同しやすいので、分けて書きます。
ひとつは、いま見たRFC 9520の規定です。解決失敗をキャッシュしてよい期間の上限が5分です。
もうひとつは、RFC 8767の側にあります。応答しない、あるいは何らかの理由で失敗している権威サーバーに対する再確認は、30秒に1回より頻繁に行わないことが推奨されています。そして実装上の考察として、この再確認の間隔を定める値が大きすぎると、権威サーバーが復旧したあとも古い答えが返り続けるため、RFC 2308のSection 7に従って5分を超えないべきだとしています。こちらの5分は、失敗したサーバーへ再確認しにいく間隔の上限です。
同じ数字ですが、一方はキャッシュを保つ時間の上限、他方は問い合わせ直す間隔の上限です。切り替えの所要時間を見積もるときに足し算の対象を取り違えると、見積もりが崩れます。記事や手順書で両方に触れるなら、どちらの5分かを必ず書き分けてください。
数字をもう1つ挙げておきます。RFC 8767は、リゾルバが利用者へ応答を返すまでに許す時間の推奨値を1.8秒としています。よくあるタイムアウト値2秒をわずかに下回る値として選ばれたものです。これは利用者から見た切り替え時間ではなく、1回の問い合わせに対する応答の待ち時間の話です。
HTTPキャッシュのTTLと同じ言葉だが、別のレイヤである
実務でTTLという語に出会う場所は、DNSだけではありません。HTTPの応答にもキャッシュの有効期間があり、アプリケーション側のキャッシュにも同じ語が使われます。
同じ言葉ですが、設定する場所も、効く範囲も、切り詰める主体も違います。HTTPの指定の読み方はno-cacheは「キャッシュするな」ではないで別に扱っています。切り替えがうまく進まないときは、まずどのレイヤのTTLの話をしているのかを確定させてください。DNSの経路を追っていたつもりで、実際には配信側のキャッシュを見ていた、という取り違えは起こります。
判断軸：いま返っている古い答えは、どの経路で返っているのか
古い答えが返っていると気づいたとき、次の順で切り分けると、対処の候補が絞れます。
- そもそもTTLが切れているか。 切れていなければ、仕様どおりの正常な状態です。待つ以外にできることはなく、次の切り替えに向けてTTLを下げておく話になります
- 権威サーバーは、いま正常に答えているか。 応答コードが0または3でAAビットが立った応答を返せているかを見ます。そうでない応答を返していた時間帯があるなら、受け取る側で前の状態が据え置かれる条件が成立しています（4番目の経路）
- 権威サーバーに到達できなかった時間帯があるか。 解決の失敗そのものがキャッシュされ、そのあいだ外向きの問い合わせは送られません。最低1秒、上限5分の範囲です
- 更新できなかった結果として、期限切れのレコードが使われている可能性があるか。 これは1番目から3番目と独立ではなく、2番目・3番目の帰結として現れます。保持期間の推奨は1日から3日で、返されるTTLは30秒が推奨値です
- TTLを長く設定したのに短く見える場合は、別の話である。 受け取る側の上限による切り詰めで、切り替えの遅さとは向きが逆の問題です
この5つのうち、手元の作業で動かせるのは1番目と2番目だけです。3番目と4番目は受け取る側の実装と設定の領域で、こちらから短縮する手段はありません。だから段取りの作り方が変わります。「何分で終わるか」を見積もるのではなく、「古い状態が据え置かれる条件を作らないこと」を当日の目標に置くことになります。
手元で確かめられる最小の手順
切り替えの前に、1つだけ数えておくと効果があります。
- 切り替えで値が変わるレコードを、すべて書き出す（Aレコードだけでなく、CNAMEやMX、関連するTXTも含めます）
- そのうち、TTLを事前に下げたレコードに印を付ける
- 印の付いていない行を数える
数えるときの定義を揃えます。
- 分子：切り替えで値が変わるレコードのうち、TTLを事前に短縮したレコードの数
- 分母：切り替えで値が変わるレコードの総数
- 単位：件／件（割合で見る場合は％）
この比率が100%でなければ、短縮し忘れたレコードがあります。見落としは、主要なホスト名ではなく、メール関連や外部サービスの認証用に置いたレコードで起きがちです。比率そのものに良し悪しはありません。分母に入れ忘れた行がないかを確かめるために数えます。
もう1つは当日の観測です。切り替え作業の前後で、権威サーバーが応答コード0または3でAAビットの立った応答を返し続けているかを記録します。ここにエラーの時間帯があれば、あとで「切り替わらない」と報告が来たときの説明が1つ決まります。何分遅れるかは分かりませんが、遅れる条件が成立していたことは分かります。
確かなことと、確かでないこと
確かなこと（2026年10月30日に2文書を取得し、本文で確認した範囲）：RFC 8767によるTTL定義の改訂内容と、その改訂が用語法の厳密化であるという同文書自身の説明。受け取る側の上限の推奨値が604,800秒（7日）であること。期限切れのレコードを使ってよい条件と、保持期間の推奨1〜3日、返すときのTTLの推奨30秒。応答コード0または3かつAAビットのみを更新成功と見なし、それ以外は前の状態を残すという規定。RFC 9520による解決失敗の定義と、キャッシュの必須化、最低1秒・上限5分、キャッシュ中は外向きの問い合わせを送らないこと。バックオフの推奨と、初期値5秒が例示であること。同じサーバーアドレスへの再試行が2回を超えてはならないこと。RFC 8767が挙げる再確認間隔の上限5分が、RFC 9520の上限5分とは別の規定であること。
確かでないこと：主要な公開リゾルバが実際に設定している最大キャッシュTTLや、serve-stale を有効にしているかどうか（今回、各社の文書を開いていません）。「TTLを300秒にしたら実際には何分かかるか」という所要時間（参照した2文書のどこにも書かれていません）。RFC 1034・1035・2181・2308の本文（RFC 8767内の引用として確認したにすぎません）。DNSSECの検証失敗に関する規定の詳細。
この記事が踏み込んでいないこと：ドメイン名そのものの仕組みはドメインとは何かで扱っています。切り替えに伴ってメール関連のレコードを触る場合、送信側の認証の設計はDMARCが保証していることが近い論点です。
切り替えの段取りを決める前に立ち返る問い
- この段取りは、何分で終わる想定になっているか。 時間の見積もりが前提になっている手順は、見積もれない量に依存しています
- 古い状態が据え置かれる条件を、当日作らない手立てがあるか。 権威サーバーが正常な応答を返し続けることは、こちらで用意できる条件です
- 古い答えが返っていると報告が来たとき、どの経路かを問える状態か。 一語でまとめた説明は、次の判断につながりません
3番目は、DNSに限った話ではありません。「浸透」のような一語は、現場の会話を速くする一方で、経路を区別する習慣を奪います。速さと区別のどちらを優先するかは、その場で決めてよい判断です。ただし区別しないと決めたことは、覚えておく必要があります。
参考資料・引用元
- RFC 8767: Serving Stale Data to Improve DNS Resiliency（2020年3月発行、Standards Track。2026年10月30日に取得・HTTP 200）
- RFC 9520: Negative Caching of DNS Resolution Failures（2023年12月発行、Standards Track。2026年10月30日に取得・HTTP 200）