DNS移動を依存関係の変更として扱う
権威DNSサービスを移行すると、電子メール ポリシーを利用可能にするインフラストラクチャが変更される一方で、レコード テキストは変更されないままになる可能性があります。移行計画には、認証レコード、メール ルーティング レコード、トランスポート ポリシーの依存関係、およびそれらを制御する当事者を含める必要があります。表示されているTXT行のコピーは、完全な受け入れテストではありません。
これは提案された移行制御ワークフローであり、プロバイダーのランブックや実行されたカットオーバーではありません。ソースは 2026 年 11 月 8 日にレビューされましたNIST SP 800-81 Rev. 3 は 2026 年 3 月の最終ガイドです。リストされている潜在的な更新ワークブックは検査されませんでした。プロバイダーの例は、引用された現在の公開ドキュメントに限定されており、顧客のプランやテナント構成は検証されていません。
レコードをサービスと所有者にマッピングする
各依存関係を正確な所有者名、レコード タイプ、制御当事者、および依存サービスごとにリストします。 MXターゲットとそのアドレス解決が含まれます。 SPF ポリシーと参照ドメイン。 DKIMセレクター レコードまたはプロバイダーの別名。 DMARC ポリシーと報告先。および関連する委任された子ゾーン。変更されていない外部プロバイダーのターゲットを区別してください。 記録 顧客ゾーンに移動中です。
デプロイされている場所にトランスポートの依存関係を追加します。 MTA-STS DNS検出レコードと別の HTTPS ポリシー エンドポイントを使用します。 DNS移行では、エンドポイントの解決、ポリシーの内容、およびポリシーのホスト名の証明書の有効性を保持する必要があります。トランスポート セキュリティは、作成者ドメイン認証に代わるものではありません。 RFC 8461
DANE 対応の受信サービスの場合は、 MXパスをマッピングします。 TLSA 記録と DNSSEC 検証チェーン。安全でない委任とDNSSEC検証エラーは、互換性のある結果ではありません。後者により、準拠した送信システムが必要な結果を確立できなくなる可能性があります。テストとエスカレーション基準の区別を維持します。 RFC 7672
SMTP TLSレポートを使用する場合はこれを含めます。そのレポート宛先と検出レコードは別個の監視依存関係であり、すべての送信者が配信を試行または完了したことを証明するものではありません。壊れたレポート パスが、トランスポートの問題が存在しないと誤解されないようにします。 RFC 8460
実際に復元できるベースラインを保存する
書き込みを承認する前に、承認されたエクスポートまたはインベントリを通じて、古いゾーンのレコード データと関連するプロバイダー設定を保持します。ベースラインがいつ取得されたか、および誰がそれを復元できるかを記録します。アカウントの役割、プロキシの動作、外部 HTTPS ホスティング、プライベート署名資料などの除外対象を特定します。ポータブル ゾーン ファイルにそれらが含まれているとは想定しないでください。
2026 年 4 月に更新されたCloudflareのインポート/エクスポートドキュメントには、製品固有の有用な警告が記載されています。インポート形式とプロキシの選択が重要であり、エクスポートとインポートには異なる権限があります。エクスポートではDNS読み取りまたはDNS書き込みがサポートされますが、インポートではDNS書き込みが必要です。これは、別のプロバイダーのエクスポートと同等になったり、トークンの作成を許可したりするものではありません。 Cloudflareインポートとエクスポート
資格情報と秘密キーは、通常の変更チケットやエクスポートされた証拠バンドルの外に保管してください。移行記録では、秘密をコピーすることなく、承認された秘密管理プロセスと責任ある管理者を特定する必要があります。バックアップ先で解釈できない、または利用可能な承認された所有者によって復元できないバックアップは、未解決の前提条件です。
権限を切り替える前に宛先を調整してください
完全なレコードセット構造、TTL、プロバイダー固有の変換を保持しながら、ソース値と提案された宛先値の比較を準備します。意図した相違点と偶発的な省略を区別してマークを付けます。インポートされたレコードの数が不十分です: 1 つのレコード内に複数のテキスト文字列があります TXTレコード 複数の独立したTXTレコードと同じではありません。 RFC 1035
提案されている読み取り専用チェックでは、どの宛先権限サーバーが照会されたか、およびどの正確な名前とタイプが要求されたかを識別する必要があります。準備された新しいゾーンからの応答と、古い委任を引き続き追跡する再帰的応答を区別します。ステージング観察をパブリックカットオーバーが発生した証拠として説明しないでください。
レジストラまたは親ゾーンの変更を実際の所有者に割り当てます。レジストラ アクセス、権限ゾーン アクセス、およびメール プラットフォーム管理は、異なるチームに属する場合があります。承認された計画では、各境界の実行者と移行を停止する権限を与えられた人物を指名する必要があります。
DNSSECとポリシー キャッシュに独自のプランを与える
署名付きゾーンの移行には、親 DS データと新しい機関が提供するキーとの関係を含む、プロバイダーがサポートするDNSSECシーケンスが必要です。 DS レコードを削除したり、検証を無効にしたりする一般的な指示を即興で作成しないでください。 Cloudflare 、 DNSSECを維持する高度な移行について文書化していますが、ソースプロバイダーが必要なDNSKEY動作をサポートする必要があります。そのルートを選択する前に、適用性を確立する必要があります。 Cloudflare DNSSEC移行
DNSキャッシュ状態と、個別にキャッシュされたトランスポート ポリシーの両方を計画します。 TTL を下げても、以前の有効期間ですでにキャッシュされている回答が遡って変更されることはありません。 MTA-STSはポリシーの存続期間にわたる動作もあります。検出レコードを削除しても、以前にキャッシュされたポリシーは即座に消去されません。 DNS のみのロールバックでは、HTTPS ポリシーの変更を元に戻すことはできません。 RFC 1034 RFC 8461
架空の計画例では、メール サーバーは変更されていませんが、 DNSホストは新しくなっています。その提案された受け入れマップは、認証名、既存のMTA-STSエンドポイント、および署名された委任を個別にチェックします。この例には、サンプル回答、インポートの成功、または移行の完了が含まれていません。
カットオーバーを承認し、実際の結果を測定する
正確な差分、観察されたベースライン、依存関係マップ、サービス ウィンドウ、および回復条件に関連付けられた人間の承認が必要です。 DNS 、委任、資格情報、および証拠共有アクションには、明示的な範囲が必要です。代理人は許可された観察を組織し、計画を草案することができます。承認なしにその分析を本番書き込みに変換したり、ゾーンを別のサービスと共有したりしてはなりません。
承認された実行後、承認された状態と承認済みの再帰的回答を比較し、制御されたメール テストから関連する認証とトランスポートの観察を収集します。部分的な結果を正直に記録します。移行が停止した場合、リカバリの決定では、単にファイルを再インポートするだけではなく、変更された委任、キャッシュの有効期間、および個別のセキュリティ ポリシーの状態を考慮する必要があります。
必要なオリジナルの証拠: 承認された正確なレコードの差分、依存関係マップ、復元資料、および変更後の検索証拠。この操作ゲートは満足されていません。この記事は準備と検証の基準を提供するものであり、承認または実行された検索証拠を提供するものではありません。