DNS変更が「反映されない」理由。TTL・伝播・切り戻しを分けて運用する

編集部の実務提案

TTLは「変更が届くまでの時間」を決める設定である

TTL（Time to Live）は、DNSレコードごとに設定されるキャッシュの保持時間である。Cloudflareの説明では、TTLは各レコードがどれだけ長くキャッシュされるかを制御し、その結果としてレコードの更新がエンドユーザーに届くまでの時間に影響する。問い合わせを受けたリゾルバは、TTLの間は権威サーバーへ聞き直さず、手元のキャッシュで答える。つまり変更の「反映」とは、世界中のキャッシュが順に切れていく過程のことである。

長いTTLには利点もある。同じ説明にあるように、TTLが長いほどキャッシュが当たる確率が上がり、DNSの名前解決は速くなる。ただしその代償として、更新が効くまでの時間も長くなる。平時の速度と、変更時の俊敏性はトレードオフであり、TTLはどちらを優先する局面かで使い分ける設定である。

数値の範囲も押さえておく。Cloudflareでは、プロキシ対象外（DNSのみ）のレコードで、TTLはプランにより最短30秒または60秒から、最長1日まで選べる。自動（Auto）の場合は300秒、つまり5分である。自社レコードの現在のTTLが何秒かを知らないまま変更当日を迎えることが、トラブルの第一歩になる。

TTLはレコード単位の設定である点も重要である。同じドメインでも、AレコードとMXレコード、サブドメインごとにTTLは異なり得る。移行対象のレコードだけを特定し、そのTTLを確認する。ドメイン全体を一括りにした「TTLは短くしたはず」は、対象外のレコードの見落としを生む。

もう一つ、TTLは「短くした瞬間」から効くのではない。TTL自体の変更も、旧いTTLのキャッシュが切れて初めて行き渡る。現在のTTLが1日なら、短縮の設定をしてから1日待たなければ、短いTTLでの運用は始まらない。変更工程は、この待ち時間から逆算して組む必要がある。

実務の落とし穴として、社内ネットワークだけ古い値を返し続けるケースがある。社内DNSが独自のキャッシュや転送設定を持っていると、外では伝播が終わっているのに社内だけ旧接続先へ届く。確認地点に社内リゾルバを含める設計は、この種の「自分たちだけ困る」状態を早期に見つけるために要る。

キャッシュの保持は、権威サーバー側の設定だけで決まるわけではない点にも触れておく。一部のリゾルバや端末は、TTLの扱いに独自の癖を持つことがある。前提として「TTLは目安であり、完全な保証ではない」と置いたうえで、重要な変更では最も遅いケースに合わせて工程と周知を設計するのが安全である。

出典：[1]

編集部の実務提案

変更の数日前から始める:TTL短縮と棚卸し

DNS変更の実務は、変更ボタンを押す数日前から始まる。第1工程は対象レコードの棚卸しである。移行するシステムに紐づくレコードを洗い出し、現在の値、TTL、プロキシの有無、証明書やメール認証など関連する他レコードとの依存を記録する。棚卸しの表が、そのまま当日の作業手順書と切り戻し手順書の土台になる。

第2工程はTTLの事前短縮である。対象レコードのTTLを、現在の値のキャッシュが切れるタイミングを見越して、変更の数日前に短い値、たとえば300秒へ下げておく。これにより変更当日の伝播は最長でも数分単位に収まる。事前短縮を省略した変更は、当日の伝播に旧TTLの全期間を背負うことになる。

TTLを変更できない局面もある。プロキシ対象のレコードでは、Cloudflareの既定でTTLはAutoの300秒に固定され編集できない、とドキュメントに明記されている。プロキシ配下のレコードは伝播が速い代わりに、TTLの設計自由度はない。自社の対象レコードがどちらの扱いかで、当日の進め方は変わる。

棚卸しでは、DNS以外の依存も確認する。接続先IPの直書きが残っているシステム、証明書の発行方式がDNS認証に依存している構成、メール送信のSPFに旧い接続先が含まれていないか。DNS変更の失敗は、DNSの外側の前提が崩れる形で現れることが多い。依存の洗い出しは変更前の工程に含める。

関係者への周知も前工程である。伝播の間は、新旧どちらの接続先へ届く利用者もいる。その間、両方のシステムが動いている必要があり、データの同期や書き込み先の扱いを決めておかなければならない。DNSの変更はネットワークの作業に見えて、実はシステム全体の移行工程の一部である。

事前短縮の工程は、変更計画の承認フローにも組み込む。短縮の実施日と、変更可能になる日を計画書に明記し、関係者の承認を得る。「なぜ数日待つのか」が説明できないと、工程が圧縮され、短縮なしの変更が再発する。仕組みの説明を計画書の定型文にしておくと、毎回の説得が不要になる。

棚卸しの表には、レコードの管理画面への参照や、変更権限を持つ担当者も記録しておく。変更の可否は権限の所在で決まることがあり、当日に「触れる人がいない」という事態は、技術以前の問題として先に潰しておくべきものである。

出典：[1]

編集部の実務提案

変更当日:一度に変えず、段階で確認しながら進める

当日の変更は、対象を小さく区切って進める。一つのレコードを変更し、伝播と動作を確認してから次へ進む。全レコードを一括で変える進め方は速いが、問題が起きたときに、どの変更が原因かを特定できなくなる。段階化は速度を落とすためではなく、切り分け可能性を保つための設計である。

変更の順序は、影響の小さいものから大きいものへ。検証用のサブドメインや、利用者の少ない経路で手順を確認し、本流のレコードに進む。手順の確認には、変更の投入方法だけでなく、確認方法と切り戻し方法の実行可能性も含まれる。本番で初めて切り戻し手順を試す進め方にしない。

変更後は、旧接続先にも新接続先にも到達があり得る期間が続く。この期間のデータの扱いが設計どおりか、書き込みが分裂していないか、旧側のログに想定外のアクセスがないかを観察する。伝播期間は「待つ時間」ではなく「両系を監視する時間」である。

完了の判定基準も先に決める。どの確認地点で新しい値が返れば伝播が進んだとみなすか、旧接続先への到達がどれだけ減れば完了とするか。判定基準がないと、完了宣言は担当者の感覚に依存し、早すぎる旧系の停止につながる。旧系の停止は、伝播完了とは別の工程として扱う。

当日の作業は記録しながら進める。変更した時刻、変更した値、確認結果。これがそのまま障害時の時系列になり、切り戻しの判断材料になる。作業中のメモを正式な記録として残す習慣が、DNS変更の属人性を下げる。

段階実施では、各段階の後に短い観察時間を置くことも有効である。伝播の進み方と、業務ログの異常の有無を見る時間である。観察時間の長さはTTLと業務の重要度で決め、手順書に数値で書いておく。観察なしの連続変更は、問題の発生時刻と原因の対応付けを難しくする。

作業当日の連絡体制も手順に含める。変更の実施、伝播の確認、業務側の疎通確認は、それぞれ別の担当が持つことが多い。誰が何を確認し、結果をどこへ集約するかを決め、判断者への報告のタイミングを区切っておく。DNS変更の混乱の半分は、技術ではなく連絡の分散から生まれる。

出典：[1]

編集部の実務提案

伝播の確認は「場所」と「リゾルバ」を分けて行う

「反映されたか」の確認で陥りがちなのは、自分の端末と自分の回線だけで判断することである。キャッシュはリゾルバごとに独立しているため、あるリゾルバでは新しい値、別のリゾルバでは古い値が返る状態は正常に起こる。確認は、複数のパブリックリゾルバと、社内ネットワークのリゾルバを分けて行う。

確認の作法として、権威サーバーへの直接の問い合わせで「正しい値が公開されているか」を先に確かめ、そのうえで各リゾルバのキャッシュ状態を見る。この2層を分けないと、設定の誤りとキャッシュの残存を混同する。権威が正しく、各リゾルバの古い値がTTL内に収まっているなら、それは異常ではなく伝播の途中である。

利用者からの申告の扱いも決めておく。「まだ古い画面が出る」という申告は、その利用者のリゾルバにキャッシュが残っている可能性を示す情報であり、設定誤りの証拠ではない。申告を受けたときの切り分け手順、リゾルバの確認方法、待つべき時間の目安を、サポート向けに用意しておく。

伝播の確認には、実際の業務経路での確認も含める。名前解決が正しくても、接続先の証明書、ファイアウォール、アプリケーション側の許可リストで弾かれることがある。DNSの変更完了と、業務の疎通完了は別の確認である。後者は業務部門と一緒に判定する。

確認結果は時刻とともに残す。どのリゾルバで、いつ、新しい値が返り始めたか。この記録は、次回の変更でTTL設計と待機時間の根拠になる。経験が数字として蓄積されると、変更計画の見積もりが現実的になっていく。

確認に使う道具も標準化しておく。主要なパブリックリゾルバへの問い合わせ、権威サーバーへの直接確認、実際の業務疎通の確認。この3点をワンセットの確認手順として文書化すれば、担当者による確認のばらつきが減り、結果の記録も比較可能になる。

申告の集計も伝播の観察に使える。申告の件数と地域・回線の偏りは、どのリゾルバでキャッシュが残っているかの手がかりになる。件数が時間とともに減っていく様子そのものが、伝播の進捗を示す実測値である。

出典：[1]

編集部の実務提案

プロキシ配下のレコードは、TTLとは別に考える

CDNやリバースプロキシを経由する構成では、DNSの見え方と実際の接続先が分離される。Cloudflareのドキュメントでは、プロキシ対象レコードのTTLはAutoの300秒に設定され編集できないとされる。これは、割り当てられたエニーキャストIPの変更が素早く効くようにするための設計であり、プロキシ配下では伝播は速い代わりに、接続先の制御はプロキシ側の設定に移る。

この構成での変更は、DNSレコードを変える作業ではなく、プロキシ側のオリジン設定を変える作業になることが多い。手順書を作るときは、変更対象が「DNSの値」なのか「プロキシの向ける先」なのかを明示する。対象を取り違えた手順は、当日に「変えたのに何も変わらない」という混乱を生む。

切り分けの観点も変わる。プロキシ経由では、利用者から見えるIPはプロキシのものであり、障害の切り分けではDNS、プロキシ、オリジンの3層を順に確認する。DNSの変更トラブルだと思っていたらオリジン側の証明書の問題だった、という取り違えは、この層の混同から生まれる。

メール関連のレコードはプロキシ対象外であることも押さえておく。MXや認証用のTXTレコードは名前解決そのものが仕事であり、Webのプロキシとは扱いが異なる。ドメイン単位で「プロキシ配下」と決めつけず、レコード単位で扱いを確認する。棚卸しの表にプロキシの有無を列として持つ理由はここにある。

プロキシの有無は、障害対応の連絡先にも影響する。DNS事業者、プロキシ事業者、サーバー事業者が分かれている場合、切り分けの結果によって問い合わせ先が変わる。変更の計画時点で、各層の管理者と連絡経路を確認しておく。

プロキシ構成では、キャッシュの層も増える点に注意したい。ブラウザやCDNのキャッシュが残っていると、名前解決が正しくても古いコンテンツが見えることがある。DNSの伝播とコンテンツのキャッシュは別の現象であり、申告の切り分けでは両方を順に確認する手順にしておく。

出典：[1]

編集部の実務提案

切り戻しは「戻す操作」ではなく「もう一つの変更」である

切り戻しの設計で最も重要な前提は、戻す操作にも伝播の時間がかかることである。変更を戻しても、変更後の値をキャッシュしたリゾルバは、TTLの間は変更後の接続先を返し続ける。「戻したのに直らない」は、切り戻しの失敗ではなく、行きと帰りの両方にキャッシュの時間がかかるという仕組みの表れである。

だからこそ、切り戻しの判断は早く行う。伝播が進むほど、利用者は新旧に分散し、戻したときの分散も大きくなる。問題の兆候を見たら、様子を見る時間の上限を先に決めておき、上限を超えたら切り戻しを実行する。判断の遅れは、そのまま混乱の期間の延長になる。

切り戻し手順は、変更手順と対で事前に用意する。戻す値、戻す順序、戻した後の確認方法、再度変更する場合の条件。旧い値の記録が棚卸しの表に残っていることが前提であり、当日になって旧値を思い出す手順は手順とは言えない。

データの観点も切り戻しに含める。新しい接続先で書き込まれたデータをどう扱うか。切り戻しによってデータが分裂する場合、その統合方法まで決めておかなければ、ネットワーク的には戻れても業務的には戻れない。切り戻しの可否は、DNSではなくデータの状態が決める場面が多い。

切り戻した場合は、原因の記録を残す。設定の誤りか、依存の見落としか、伝播の見積もり違いか。切り戻しは失敗の隠蔽ではなく、次の変更計画への入力である。記録のない切り戻しは、同じ失敗を繰り返す。

切り戻しの訓練も一度は実施したい。小さなサブドメインで、変更と切り戻しを通しで演習し、手順の詰まりと確認の抜けを洗い出す。DNSの切り戻しは本番の緊張下で初めて試すには影響範囲が大きい。演習の記録は、手順書の改版材料にもなる。

切り戻しの実施後は、再度の変更に向けた条件整理も同じ案件の中で行う。原因が解消されたか、次回はTTLや段階の切り方をどう変えるか。切り戻しで終わらせず、再実施の設計までを案件の完了条件に含めることで、変更は一度の失敗で止まらなくなる。

出典：[1]

編集部の実務提案

変更を台帳に残し、次の変更を楽にする

DNSの変更履歴は、ドメインとレコードごとに残す。変更前後の値、TTL、変更日時、目的、実施者、確認結果、切り戻しの有無。この履歴があれば、数年後に「このレコードはなぜこの値なのか」に答えられる。DNSは触る頻度が低い分、意図の記録がないと誰も触れなくなる。

定期的な棚卸しも組み込む。使われていないサブドメイン、退役したシステムを指したままのレコード、担当不明のレコード。不要なレコードは、移行時の障害要因であると同時に、放置された接続先というセキュリティ上の問題にもなる。変更のたびの棚卸しと、年次の棚卸しの両方を回す。

TTLの平時設計も見直す。変更が頻繁なレコードは短めに、安定した基幹レコードは長めに、という配分を、変更履歴の実績から決める。すべてのレコードを一律の値にする必要はない。変更頻度というデータが、TTL設計の根拠になる。

証明書や認証との連携も台帳に含める。DNS認証で発行される証明書の更新方式、SPFやDKIMの対象レコード。これらはDNS変更の影響を受けやすい隣接領域であり、変更チェックリストの確認項目に入れておくことで、変更起因の二次障害を防げる。

DNSは地味だが、すべての接続の入り口である。その変更を、事前の短縮、当日の段階実施、伝播の確認、切り戻しの準備、履歴の記録という型ある工程にできれば、移行当日の混乱は大幅に減る。型は一度作れば、担当者が替わっても残る。

台帳は、変更の申請と承認の記録とひも付けて保管する。値の履歴だけでは「なぜ変えたか」が残らない。申請の目的と承認者の記録が対になっていれば、監査対応も、将来の担当者への引き継ぎも、一つの台帳で完結する。

最後に、この型を小さな変更で先に試すことを勧めたい。影響の小さいレコードの変更で、棚卸しから記録までの一連を一度通しておけば、本番の移行では手順の不安が消える。型の価値は、大きな変更の前に小さな変更で検証されていることにある。

変更の型が組織に残ることは、ベンダーや担当者の変更に対する耐性にもなる。手順が文書として存在すれば、新しい担当者は過去の判断をたどることができ、同じ検討を一から繰り返さずに済む。

出典：[1]