承認されたオブジェクトをデプロイ可能なオブジェクトにする
DNS変更パイプラインは、公開する前に、具体的な質問に答える必要があります。つまり、これは責任ある所有者がレビューした正確なレコード変更ですか?構文チェックが成功しても、その質問に答えることはできません。有効な SPFレコード 間違ったサービスを承認する可能性があります。整った形の DKIM キーは、キューに入れられたメールを検証するキーと置き換えることができます。したがって、パイプラインには、技術的な検証と、不変の提案されたコンテンツに関連付けられた決定記録の両方が必要です。
以下のワークフローは、すべてのDNSプラットフォームがこれらの機能を提供するという主張ではなく、提案された運用制御として扱ってください。バージョン管理されたベースラインから開始し、正確な差異を生成し、その差異に対する承認を集めて、実行直前にベースラインを再チェックします。有効な記録がレビュー後に変更されている場合は、調整のために停止します。緊急編集を古い承認済み計画と黙って組み合わせないでください。
レコードレベルの変更パッケージを構築する
完全修飾所有者名、クラス、タイプ、TTL、および完全なレコードセット値によって、意図されたすべての追加、置換、および削除を説明します。権限のあるゾーン、その現在の委任、 DNSプロバイダー アカウント、およびレコードを使用するサービスを含めます。登録の所有権と権威ホスティングは別個の依存関係です。のゾーンと委任モデル RFC 1034セクション 4.2 は、便利なコントロール パネルを変更しても、必ずしも公開された権限が変更されるわけではない理由を説明しています。
レコード境界を保持します。 1 つの文字列内に複数の引用符で囲まれた文字列 TXTレコード 独立して選択された複数のポリシーではありません。 RFC 1035セクション 3.3.14 TXTデータを 1 つ以上の文字列として定義します。確認のために、プロバイダーの表現と結果の論理値の両方を表示します。置換操作によって同じ名前の無関係なTXTデータが誤って消去されないように、影響を受けるセット全体を記録します。
送信者インベントリ、依存関係マップ、提案されたチェックを添付し、資料を復元します。ビジネスへの影響を承認できる人、技術的な変更を承認できる人、および変更を実行できる人を記録します。プラットフォームがスコープ付き書き込みアクセスをサポートしている場合は、実用的な最小スコープを優先します。より広範な許可を明示的な暴露として文書化します。 NISTの DNS導入ガイド ゾーンのコンテンツを保護し、許可された送信者からのみ動的更新を受け入れることについて説明します。ここでの承認設計は、その懸念をレビュー可能な運用プロセスにまで拡張します。
承認を求める前にセマンティクスを検証する
提案されたバリデータは、不正なデータを望ましくないポリシーから分離する必要があります。所有者名の拡張、レコード タイプ、重複ポリシー レコード、エイリアスの競合、および予期しない削除を確認します。次に、消費者のルールを調べます。 SPF バージョン文字列で始まるレコードを選択し、一致するポリシーが複数残っている場合は永続的なエラーを返します。 DNS に依存する評価にも制限が定義されているため、表示される include ステートメントだけをカウントするだけでは不十分です。これらは次のような個別のチェックです。 RFC 7208セクション 4.5 および 4.6.4.
DKIM変更する場合は、実際の署名ドメインを特定し、 セレクタ、古いキーを利用可能なままにしておく必要があるかどうかを確立し、サービス所有者に意図した署名構成を確認するよう要求します。ルックアップ名は、推測されたプロバイダーのデフォルトではなく、署名値から派生します。 RFC 6376セクション3.6.2.1。 DNS のみのバリデーターは、対応する秘密キーが使用されていることを証明できません。
記録された決定を必要とする警告と、展開をブロックする必要があるエラーを区別します。たとえば、所有されていない外部SPF依存関係では、構文が正しい場合でもリスク レビューが必要になる場合があります。必要なベースラインが欠落していると、影響も復元も確実に評価できないため、実行がブロックされます。
計画とその前提条件に承認を拘束する
レビューされた差異、関連するベースライン、および証拠パッケージの安定したダイジェストまたはバージョン識別子を含めます。承認には、環境、記録、意図された結果、および有効期限条件を指定する必要があります。新しい値、追加の削除、権限の変更、または大幅に異なる依存関係については、再度レビューする必要があります。これにより、チケット タイトルに添付された承認が別の操作に再利用されるのを防ぎます。
実行者は、プロバイダーの証拠なしにバッチ リクエストをアトミックとして扱うのではなく、部分的な失敗を報告する必要があります。再試行する前に、どのレコードが変更されたかを確認してください。現在の状態をベースラインと意図した結果の両方と比較し、最小の修正計画を作成します。不確実な結果は観察する理由であり、すべての書き込みを再実行する理由ではありません。
ブロックされたリリースの架空の実際の例
架空のドメインexample.comについて考えてみましょう。その通知サービスは新しいDKIMセレクターを要求し、別のチケットは古い検証TXTレコードを破棄します。エクスポート ツールがTXTセット全体を 1 つの編集可能なセルとして扱ったため、提案されたパッケージには 2 つの削除が含まれています。レビュー担当者は、無関係な検証値が消えることを認識し、そのパッケージそのものを拒否します。
改訂された計画では、セレクター レコードのみが変更され、他のTXT値は保持されます。メール所有者は提案された署名切り替えシーケンスを提供しますが、 DNS所有者は復元のために以前のレコード セットを保持します。承認には、新たなベースライン比較が条件となります。これらは、コントロールを説明するために作成されたレビュー イベントです。この原稿に関しては、記録の照会、承認、展開は行われていません。
証拠を持って実行ループを閉じる
承認された展開後、オペレーターはタイムスタンプ付きの信頼できる回答と選択された再帰的観察を保持し、それらを制御されたメッセージの結果に結び付ける必要があります。実際の所有者の名前とタイプを承認されたパッケージと比較します。プロバイダーの成功応答は実行の証拠として役立ちますが、公開されたことや認証が成功したことの独立した証拠ではありません。
意図しないレコード、使用できないキー、予期しない正当なメールの失敗など、展開前にロールバック トリガーを定義します。ベースラインを復元すると、権限のある状態が変わります。以前にキャッシュされた回答は消去されません。元の証拠のゲートは、承認された正確なレコードの差分、依存関係マップ、復元資料、および変更後の検索証拠が存在するまで開いたままになります。この原稿では、これらのテナント固有の実行アーティファクトは提供しません。