バックアップを回復用の質問に答えるようにする
認証レコードを変更する前に、何が公開されたか、プロバイダーが何を保存したか、および意図した変更をどのように元に戻すことができるかを説明するのに十分な情報を保存してください。ダウンロードされたゾーン ファイルは便利ですが、その存在は復元によってサービスが再作成されることを証明するものではありません。バックアップを、所有者、キャプチャ時間、および明示的な制限を備えたリカバリ パケットとして扱います。
このガイドでは、具体的なプロバイダーの例として、2026 年 11 月 8 日にレビューされたCloudflareのパブリックDNSインポートおよびエクスポートに関するドキュメントを使用します。ワークフローは提案された制御であり、ここで実行されたエクスポートまたは復元のレポートではありません。プロバイダー インターフェイスとアカウント機能は、運用前に確認する必要があります。この方法を理解するために、資格情報、秘密署名キー、実稼働ゾーンのデータは必要ありません。
ゾーンと変更境界を特定する
ファイルを収集する前に、正確なゾーン、アカウント、および権限のあるプロバイダーを書き留めてください。登録と権限のあるホスティングは、異なる組織に属することができます。子ゾーンには独自の所有者を持つこともできます。親からのエクスポートでは、委任された子の内容は確立されません。影響を受ける名前が委任の下にある場合、 DNS階層によってその区別が重要になります。 RFC 1034
スコープ内の名前と型をリストします。 SPF TXTオーナー、 DKIMセレクター オーナーさん、 DMARC 保険契約の所有者またはベンダー CNAME ターゲット。重要と思われる文字列のみをコピーするのではなく、関連するレコード セット全体を保存します。将来の修復でサービス検証レコードが誤って削除されないように、同じ所有者の無関係なTXTデータを記録してください。要求された変更は、周囲の在庫とは別に保管してください。
プロバイダーのデータと公開観測を個別に取得します
Cloudflare 、「インポート」と「エクスポート」、そして「エクスポート」を通じて、 DNSレコード」ページからのエクスポートを文書化します。その API の代替手段は、 DNS読み取り権限を受け入れる GET 操作です。これは、トークンの作成やアカウントへのアクセスの許可ではなく、承認されたオペレーターのルートを文書化します。すでに承認されている読み取りパスを優先し、結果をチームの制限された証拠の場所に保存します。 Cloudflareインポートとエクスポート
ダウンロードしたバイトを変更せずに保存します。作業用コピーをレビュー担当者に渡し、チェックサム、UTC キャプチャ時間、ゾーン ID、演算子を含むオリジナルを保持します。チェックサムは後続のバイト変更を検出します。オリジナルが完全であること、正しいこと、または正しいアカウントから収集されたものであることを証明するものではありません。エクスポートが変更の凍結の前に行われたかどうか、および収集中にまだ誰かがゾーンを編集できたかどうかを記録します。
提案されたパブリック チェックの 2 番目のインベントリを作成します。正確な所有者、タイプ、権威サーバー、再帰リゾルバー、タイムスタンプ、応答ステータス、返されたデータ、TTL です。これらのチェックでは、その時点でサーバーが何を応答したかが表示されます。これらはプロバイダーのエクスポートを置き換えるものではなく、エクスポートはそれらを置き換えるものでもありません。ここでは検索結果は提供されません。オリジナルの信頼できる再帰的トランスクリプトは引き続き必要な証拠となります。
ポータブル ファイルでは復元できない部分を保存する
Cloudflareの文書化されたエクスポートには、選択したレコードの動作に関するコメント、タグ、および特別なタグが含まれています。特に、そのプロキシ状態タグはインポート動作に影響を与え、タグが存在しない場合、動作が一般的なインポート オプションに依存する可能性があります。ファイルを別のサービスに移動する前に、これらの属性を保存し、その意味を確認してください。別のプロバイダーは、Cloudflare 固有のコメントを設定として解釈する必要はありません。 Cloudflareレコードの属性
レジストラの委任用に別の依存関係シートを保持します。 DNSSEC 管理、トラフィック ルーティング機能、アカウントの所有権、送信者の構成。キャプチャされた各アイテム、個別にバックアップされたアイテム、または範囲外のアイテムをマークします。ゾーン ファイルにアカウントの完全バックアップというラベルを付けないでください。 DNS TXTレコード を含む DKIM 公開キーは、送信者が使用する秘密キーではありません。秘密キーの保管は、通常のゾーン バックアップ チケットではなく、別の承認されたシステムに属します。 RFC 6376
何かを変える前に狭い反転を設計する
この架空のレビュー ケースを考えてみましょう。Web サイト チームが無関係なアドレス レコードを編集している間に、チームはexample.comで 1 つのSPF TXTレコードを置き換えることを計画しています。回復提案では、以前のSPF値とその所有者の現在のすべてのレコードを特定する必要があります。古いゾーン全体のスナップショットを復元すると、Web サイト チームの正当な編集内容が消去される可能性があります。したがって、デフォルトの復旧提案は、正確な記録の取り消しを検討し、ゾーン全体の復旧を別途正当化されたインシデント計画のために予約する必要があります。
取り消しをトリガーする条件、決定を許可される人物、オペレーター、および検証手順を指定します。以前の値がまだ安全かどうかを確認してください。廃止されたベンダーまたは侵害されたキーは、単に昨日のスナップショットに現れたという理由だけで復活させてはなりません。元に戻すことができるファイル編集は、自動的に安全な操作ロールバックになるわけではありません。後で承認された書き込みの前に、ライブの意図されたスコープを再度比較します。
復元リハーサルでは、分離された承認された宛先を使用し、解析、レコード セット、およびプロバイダー属性を検証する必要があります。ファイルの読み取りはリハーサルではなく、本番環境へのインポートは無害なテストではありません。 Cloudflareは256 KiBのインポート制限が記載されているため、有効なエクスポートであっても宛先固有の復元チェックが必要です。この記事ではリハーサルやインポートは行われていません。 Cloudflareインポート制限
成功を誇張せずに証拠パケットを閉じる
リリース チェックリストでは、変更されていないソース ファイル、そのチェックサム、正確なレコードの差分、省略された依存関係、および提案されたリバースを指定する必要があります。また、誰が資料をレビューしたか、どの証拠がまだ欠けているかも記録する必要があります。多くのDNS値が公開されている場合でもアクセスを制限します。統合されたインベントリとプロバイダーのコメントにより、1 回の公開検索では明らかではない運用の詳細が明らかになる可能性があります。
独立して承認された変更または取り消しの後、承認された意図と承認された再帰的観察を比較します。キャッシュには以前の回答が保持されるため、復元されたコントロール パネルの値がすべての受信者の見解を即座に確定させるわけではありません。以前の値と置換後の値、観察時間、キャッシュ関連の不確実性をまとめて保存します。 RFC 2308
有用な結果は、オペレータが推測することなく評価できる回復パケットです。ダウンロードしたファイルによってメール配信が復元されることを保証するものではありません。送信者の動作と受信メッセージの証拠には依然として独自の検証が必要であり、該当するチェックが実際に実行されるまで、元の実行ゲートは開いたままになります。