伝播期限を変更計画に置き換える
DNS TTL は、キャッシュされた情報がいつ再検討されるかを決定するのに役立ちます。すべての受信機が代替品を使用し始める世界的な瞬間をスケジュールするわけではありません。 SPF 政策とか DKIM 鍵。異なるリゾルバーが異なるタイミングで古い回答を取得し、権限のあるサーバーがすべて新しいデータを提供しているわけではない可能性があり、アプリケーションは独自の検索および再試行動作を行う可能性があります。
有用な変更計画は、権威ある出版物と下流の観察を区別します。 「 DNSホストが編集を受け入れた」ということは、「関連する権威サーバーが意図した応答を返した」ということよりも早いマイルストーンです。どちらのステートメントも、特定のメール受信者が 1 分前に送信されたメッセージに何を使用したかを証明するものではありません。 DNSは一定の時間がかかるという一般的な約束ではなく、各マイルストーンの証拠を基にタイムラインを開始します。
どの TTL が監視されているかを理解する
信頼できるリソース レコードには、公開されたデータに関連付けられた TTL があります。キャッシュされた応答は通常、キャッシュされたデータの残りの有効期間を報告するため、2 つの再帰リゾルバーは異なる残り TTL を持つ同一のテキストを返す可能性があります。これらの値はさまざまなキャッシュ状態を表します。これらは、レコードの意図された構成の 2 つの競合する宣言ではありません。 RFC 1035 、セクション 4.1.3; RFC 1034 、セクション 6.2.1.
既存のレコードの TTL が長い場合、その値を減らしても、古い回答がすでに格納されているキャッシュには遡りません。大幅な変更に先立って削減を計画し、以前のキャッシュ期間を考慮できるようにします。保守計画の一部として扱う前に、下位 TTL が実際に提供されていることを確認してください。これは計画に関するガイダンスであり、すべてのキャッシュが観察されたことを証明するものではありません。
エイリアス チェーンは個別の依存関係を追加します。エイリアス レコードとターゲットのレコード セットには、異なる TTL と異なる演算子を含めることができます。顧客側の短い TTL CNAME すでにキャッシュされているターゲット キーを同時に強制的に更新することはありません。タイミングを説明する前に、両方の名前を書き留めてください。
古い答えと新しい答えを別々にモデル化する
次の架空のSPFアップデートについて考えてみましょう。 mail.example.com。リゾルバ A は、09:50 に 3,600 秒の TTL で古いポリシーを取得します。 10:00 に、権限のあるオペレーターは公開された TTL を 300 に変更します。10:10 に、オペレーターはポリシーを置き換えます。リゾルバー A の以前のエントリは、他の動作がない限り、10:50 までは元のキャッシュ有効期間内で引き続き使用できます。最初に 10:10 以降を検索する 2 番目のリゾルバーは、すでに置換を返している可能性があります。
この実際の例は計算を発明したものであり、測定や保証された有効期限スケジュールではありません。その教訓は、10:00 で TTL を下げても、リゾルバー A の 09:50 エントリは書き換えられないということです。運用ワークシートには、以前のデータ、以前の TTL、認証局で TTL 変更が観察された時間、コンテンツが変更された時間、およびその後のサンプリングされたリゾルバー応答が保持されている必要があります。
DKIMローテーションの場合、新しいリリースを公開するために別のマイルストーンを保持します。 セレクタ、その可用性を確認し、それを使用する署名を開始し、古いセレクターを廃止します。 DNSキャッシュの計算だけでは、以前に送信されたメールの検証がいつ完了するかを決定できません。送信者のキューイング、再試行、保持の要件もローテーションの決定に含まれます。 RFC 6376 、セクション 3.1 および 3.6.
否定的な回答と停止動作を含める
新しく作成された名前には、古い肯定的な記録が存在しない可能性があります。リゾルバーは代わりに、以前のNXDOMAINまたはNODATA結果を保持することもできます。否定応答の SOA ベースの有効期間は、新しく公開された応答の TTL とは異なる値です。 TXTレコード。したがって、新しいTXT TTL を変更しても、以前にキャッシュされた不在は消去されません。 RFC 2308 、セクション 3 および 5.
単純な有効期限の話に対する明示的な標準例外もあります。 RFC 8767では、期限切れのエントリを正式に更新できない場合に、古いデータを提供することが許可されています。これが発生するかどうかは、リゾルバと障害の状況によって異なります。ゼロ以外の小さい TTL があるというだけの理由で、返された回答が新しいと想定しないでください。 RFC 8767のセクション 4 ～ 5.
このような事件では、恣意的な追加待機期間を招くのではなく、捜査を変更すべきである。当局が同意しない場合は、出版物の一貫性を修正します。否定的な応答が続く場合は、元の質問と SOA コンテキストを調べてください。権限に到達できない場合は、すでに正しいTXTレコードを繰り返し編集するのではなく、復元または可用性を調査してください。
リリースの質問に答える観察を選択してください
変更前に、関連する機関と選択した再帰パスから正確なレコードとその TTL を取得します。その後、同じエンドポイントに対して同じ所有者、タイプ、クラスを繰り返します。可能な場合は、影響を受ける環境に関連するパスを含めます。いくつかのパブリック リゾルバーはサンプルのままであり、すべてのメール受信者の調査ではありません。
提案されたクエリは、 @RESOLVER_IP mail.example.com掘ります。 TXTとペアになっています @AUTH_IP mail.example.comを掘ります。 TXT +norecurse。使用する前に、完全な応答を UTC タイムスタンプとともに保存し、すべてのプレースホルダーにラベルを付けます。ローカル キャッシュ フラッシュでは、そのローカル キャッシュ パスのみが変更されます。リモート受信者の再帰キャッシュをクリアできないため、グローバル完了制御ではありません。
どの当局が同意するか、どのサンプリングされたリゾルバーが新しい値を返すか、どの観測値が欠落したままになるかなど、結果を正確に報告します。次に、目的のサービスを通じて制御されたメッセージを送信し、実際の認証 ID と受信者の結果を検査します。このドラフトでは、 DNSクエリやメッセージ テストは実行されませんでした。 TTL、応答タイプ、権限、観察時間を含む、必要なリゾルバー比較はオープンなままです。