DNS変更を自動にする前に確認できるようにする
コードとしてのインフラストラクチャは、認証レコードに明示的な所有者、レビュー可能な履歴、および反復可能な変更プロセスを与えることができます。また、多くの名前で間違いをすぐに繰り返す可能性もあります。したがって、目標は、デプロイメントの承認とDNS検証をコード レビューの成功とは切り離して、特定されたレコード セットへの変更を制御することです。
この記事では、2026 年 11 月 8 日にレビューされた時点で v1.17.x として表示されていた Terraform CLI ドキュメント ブランチを使用します。これはワークフローの説明であり、プロバイダー固有の構成レシピやインストールされたリリースに関する主張ではありません。実装するには、正確な Terraform パッチ、 DNSプロバイダー プラグインのバージョン、バックエンド、アカウントを記録する必要があります。ここでは、プロバイダーの初期化、計画、展開、資格情報の操作、またはDNS変更は実行されていません。
リポジトリが所有するものを定義する
まず、正確な所有者名、タイプ、レコードセット境界の一覧表を作成します。担当チームの名前をあげてください SPF、 それぞれ DKIMセレクター, DMARC ポリシーおよびプロバイダー管理のエイリアス。同じリポジトリで管理されていない場合でも、委任されたゾーンと外部ターゲットを依存関係マップに含めます。あ CNAME 別の組織のDNSおよびサービス ライフサイクルに応じてローカル構成を行うことができます。 RFC 1034
既存のレコードをツールにインポートする前に、重複する所有権を解決します。 DNSパネルと 2 つの自動化システムがすべて同じセットを要求する場合、きちんとしたプル リクエストを行っても、一方が他方の作業を元に戻すことはできません。緊急時の手動編集とその後の調整のプロセスを確立します。すべての外部変更を不正なドリフトと呼ばないでください。まず、宣言された構成が依然として承認されたインテントであるかどうかを判断します。
架空の場合 DKIM ロールアウトすると、マップは新しいセレクターのパブリックDNSマテリアルを、そのセレクターで署名する送信者に接続する必要があります。秘密署名キーは、一般的なDNSリポジトリではなく、承認された署名システムに属します。公開キーを公開するだけでは、送信者の動作は変わりません。 RFC 6376
変更の一部として依存関係を記録する
Terraform のバージョン要件、選択したプロバイダーのバージョン、およびレビューに関連するモジュールのバージョンを保持します。 HashiCorp は、依存関係ロック ファイルにプロバイダーの選択とチェックサムが記録されることを文書化しています。同じ方法ではリモート モジュールの選択をロックしません。実際的な場合は、依存関係の変更を個別に確認してください。 記録 edit ではプロバイダーのアップグレードが隠蔽されません。 Terraform 依存関係ロック ファイル
既存の状態と回復マテリアルは、組織の承認されたアクセス制御の下に保管してください。状態はツールによって使用されるマッピングであり、読み取り可能なゾーンのベースラインやレコード レベルの反転計画の代わりとなるものではありません。大きな影響を与える移行の前に、プロバイダーのデータと意図された現在の公開回答を取得します。チームが復元できない依存関係と、それらの回復手順の所有者を記録します。
実際の計画から検証を分離する
提案されたコマンド テラフォーム検証 すでに初期化されている作業ディレクトリ内の構成の一貫性をチェックします。プロバイダーのライブ API やリモート サービスは検証されません。ドキュメントの演習中にプラグインをインストールしたり、バックエンドを初期化したりする理由にはなりません。オペレーターはまず、必要な環境と依存関係がすでに許可されていることを確認する必要があります。 Terraform の検証
提案されたコマンド テラフォーム計画 変更をプレビューし、通常は既存のリモート オブジェクトを読み取ります。提案されているインフラストラクチャの変更は適用されませんが、オフラインのテキスト チェックではありません。プロバイダー、資格情報、データ ソース、および状態アクセスが関係する可能性があります。計画を立てる前に、構成と実行環境を確認してください。デプロイメントがないからといって、資格情報の処理が無関係になるわけではありません。 テラフォーム計画
読み取り可能な計画を、特定の構成、状態、観察時間の証拠として扱います。アカウントの状態が後で変更された場合、以前のプレビューが最終的な操作を説明しているとは想定できなくなります。グリーンプランが安全性や実現可能性を証明するという大げさな約束は避けてください。これは、提案されたポリシーが賢明であることを証明するものでも、受信側システムが結果のデータを取得できることを証明するものでもありません。
正確なDNS効果を確認する
提案されたレビュー シートでは、ゾーン、所有者、タイプ、古い値、新しい値、TTL、およびすべての作成、更新、または削除を特定する必要があります。固定プロバイダーのドキュメントで置換セマンティクスを説明します。コード内の 1 つのリソースがレコード セットを表す場合があるため、レビュー担当者は無関係な値を削除できるかどうかを理解する必要があります。そのマッピングが不明瞭な場合は、変更を承認する前に停止してください。
構文テストのみではなく、認証固有のチェックを使用します。提案されたSPF代替では、承認された送信設計を保持する必要があります。セレクターのローテーションには送信者の移行計画が必要です。 DMARCポリシーの変更には、施行に関する責任ある決定が必要です。これらはレビュー用の質問であり、新しい送信サービスやポリシーのコミットメントを推測するための自動化の許可ではありません。承認を正確な結果的な差分に結び付けてください。
架空のセレクターのロールアウトでは、送信者の移行前に新しいルックアップの依存関係を検証する必要があり、古いセレクターを安全に廃止できる時期を文書化します。リポジトリをきれいに保つためだけに、最初の公開に以前のキーの削除をバンドルしないでください。タイミングは、パイプラインにコピーされた一般的な数値ではなく、承認されたメール ワークフローと観察された証拠に従う必要があります。
レビュー成果物を構成と同じくらい慎重に保護する
保存された計画には、端末出力で非表示になっている場合でも、機密性の高い値が含まれている可能性があります。 Terraform の機密性の高いマーキングは、それ自体では、値が状態ファイルや計画ファイルから除外されるわけではありません。認証情報、秘密キー、編集されていないアーティファクトをプル リクエストや広範なチャット チャネルに配置しないようにします。承認されたレビュー担当者と最小限のレビュー資料のみを共有します。 Terraform の機密データ
状態を読み取ることができる人、計画を要求できる人、展開を承認および実行できる人を指定します。後のデプロイメント環境に広範な書き込み権限が必要であるという理由だけで、レビュー環境には広範な書き込み権限が必要ありません。資格情報の作成または権限の拡張は、それ自体が承認されたセキュリティ アクションであり、コードとしてのインフラストラクチャの導入の暗黙的な部分ではありません。
ロールバックと検証を新しい作業として扱う
コミットを元に戻すと、宣言された意図が変更されます。 DNS即座に復元するわけではありません。ロールバック提案には、現在のレコードとの新たな比較、計画の見直し、古い値が安全であることの確認が必要です。古いベースラインを再適用すると、正当な同時編集が消去されたり、廃止された送信者の依存関係が復活したりする可能性があります。キャッシュされた回答は、順方向または逆方向の変更後も保持されます。 RFC 2308
独立して承認された展開後は、正確で信頼できる再帰的検索の証拠と、関連するメールの観察結果を保持します。実際の状態が承認された結果と一致する場合、または残りの不一致に所有者がいる場合にのみ、変更を閉じます。この原稿の正確なレコードの差分、依存関係マップ、復元資料、および変更後のトランスクリプトは依然としてリリース要件です。文書化されたワークフローはその証拠の準備であり、展開が成功したという証拠ではありません。