仕様と実装範囲を記載する
Domain Connect は、サービス プロバイダーが、連携するDNSプロバイダーを通じてDNSを構成するのに役立ちます。保存されている公式リポジトリのドキュメントは、バージョン 2.3 であることを示しており、同期フローと非同期フローについて説明しています。この記事では、そのバージョン管理されたソースを解釈します。すべてのプロバイダーが両方のフローをサポートしているとは主張しませんし、後の標準提案のステータスを確立するとも主張しません。ワークフローを運用的に使用する前に、特定のプロバイダーの統合とテンプレートを確認してください。
自動化により手動でのレコード入力が減りますが、ドメイン、既存のサービス、または承認に対する責任がなくなるわけではありません。接続リクエストにより、メール、Web サイト、検証プロセスで使用される記録が変更される可能性があります。レビュー担当者は、見慣れたサービスのロゴを十分な証拠として扱うのではなく、提案された効果、現在の権限、およびそれを承認するアカウントを理解する必要があります。 ドメイン接続仕様、バージョン 2.3
1 回限りの同意を継続的な許可から分離する
保持された同期フローでは、ユーザーはDNSプロバイダーに誘導され、必要に応じて認証され、プロバイダーはユーザーがDNSゾーンを制御していることを確認します。プロバイダーは、指定されたパラメーターを検証し、変更への同意を求めます。これは特定のフローの説明であり、この原稿に対して実際のアカウントまたはドメインが検証されたことを証明するものではありません。
同じバージョンで説明されている非同期フローでは、OAuth アクセスが許可されるため、サービス プロバイダーは後でテンプレートを適用できます。その権限の範囲は、要求されたテンプレートと、ユーザーの制御下にある指定されたドメインおよびサブドメインに限定されます。継続的なアクセスは、現在の 1 回のDNS編集とは大きく異なります。 1 回のクリックが 1 回の変更のみを意味すると仮定するのではなく、その範囲、期間、失効プロセス、および責任のある所有者を個別に確認してください。
資格情報、認証コード、またはトークンを変更ワークシートまたは記事の証拠に含めてはなりません。実際のアクセス許可には、独自の承認と安全な処理が必要です。この原稿はログインを開始したり、永続的なアクセスを作成したりしません。 Domain Connect: 同期フローと非同期フロー
具体的な記録のレビューを要求する
テンプレート識別子、プロバイダーおよびサービス識別子、テンプレートのバージョンまたはコンテンツ ハッシュ、ドメイン、置換パラメータ、および提案されたレコード セットを保存します。意図した結果を現在の正式な状態と比較します。既存のサービスをサポートするレコードを含む、追加、置換、および削除を特定します。レビューでは、テンプレートの汎用変数と、特定のドメインに提案された実際の値を区別する必要があります。
保持されている仕様では、開示と競合検出は実質的にDNSプロバイダーに委ねられています。レコードを表示したり、競合について警告したり、重複するテンプレートを別の方法で処理したりする実装について説明します。したがって、すべての同意画面に完全な差分が表示されることや、既存の依存関係がすべて保護されることを約束するものではありません。組織によっては、プロバイダーのインターフェイスに表示される最小限の情報よりも詳細なレビューが必要な場合があります。
インターフェイスで十分な情報が公開されていない場合は、サポートされているドキュメントまたは承認されたレビュー パスを通じてその影響が理解されるまで、変更を一時停止してください。隠れた競合が無害であると推測しないでください。必要な組織的な証拠は、単に「続行」ボタンのスクリーンショットではなく、理解できる変更案です。 Domain Connect: 変更と矛盾の開示
テンプレートを評価して競合を記録する
新しいテンプレートは、以前のテンプレートまたは手動編集によって管理されているレコードと重複する可能性があります。保持された仕様は、テンプレートの状態を維持するプロバイダーが以前の重複するテンプレートを削除し、最初に注目を集めた単一の競合を超えてレコードに影響を与える可能性があることを示しています。そのため、新しいサービスに必要なDNSレコードが 1 つだけであるように見える場合でも、依存関係のレビューが重要になります。
For authentication work, identify existing SPF ポリシーの境界線、 DKIM セレクター、 DMARC ポリシーおよび承認前の検証記録。 Do not invent a provider-specific include or セレクタ 一般的な例から。対象となるレコードは、実際にサポートされている構成から取得する必要があります。テンプレートが既存の値を置き換える場合は、どの所有者が置き換えを確認するか、および正当な送信ルートがどのようにカバーされ続けるかを確立します。
テンプレートの更新にも注意が必要です。保存されているドキュメントでは、変更されたテンプレートをDNSプロバイダーにオンボーディングすることと、透明性を確保するためにバージョン フィールドを使用することについて説明しています。以前の承認では、実質的に異なるテンプレートやパラメータ セットを黙ってカバーすべきではありません。レビューされたバージョンを保持し、プロバイダーの現在サポートされているフローが同じ意図された変更に解決されるかどうかを確認します。 Domain Connect: テンプレートのバージョン管理とレコード タイプと競合
受け入れワークシートと回復計画
ワークシートには、ドメイン権限、承認アカウントの役割、サービスの目的、テンプレート ID、ソースの日付、正確な提案レコード、現在のレコード、競合、影響を受けるアプリケーション、およびロールバック所有者を含める必要があります。 1 回限りのアクセス許可と継続的なアクセス許可、そのサポートされる範囲、取り消し手順については、別のアクセス セクションを追加します。技術アカウントへのアクセスがビジネス承認と等しいと仮定するのではなく、実際の承認決定を記録してください。
実行前に計画を検証します。完了画面はインターフェイスの状態の証拠であり、有効な権威DNSまたは動作しているメッセージ認証を自動的に証明するものではありません。受け入れ計画には、変更後の信頼できる回答の保持と、必要に応じて、影響を受けるルートに関する個別に承認されたメッセージ証拠が必要です。再帰的な観察とキャッシュの制限は、普遍的な即時伝播を約束せずに文書化する必要があります。
回復には、サポートされているルートと現在の以前の状態のスナップショットが必要です。古いゾーンをやみくもに復元すると、正当な同時作業が上書きされる可能性があります。最小の是正措置、それを承認できる所有者、および回復を確認するために必要な証拠を特定します。これらは提案された計画要件であり、トランザクションまたはロールバックが実行されたという主張ではありません。
架空のレビュー: サービス接続が既存のメールと重なる
テンプレートがメール ワークフローで既に使用されている名前でTXT変更を提案する架空のサービス接続を想像してください。 DNSプロバイダーの同意画面では新しいサービスに名前が付けられますが、既存の値が置き換えられるかどうかを判断するのに十分な詳細は表示されません。この例では、実際のテンプレートは適用されず、ドメインもクエリされませんでした。
レビュー担当者は提案された正確なレコードを要求し、既存のメール依存関係の所有者を特定します。インタラクションが理解されるまで、承認は保留のままになります。フローが継続的なアクセスも要求する場合、その要求は別のスコープ レビューを受け取ります。ユーザーがDNSアカウントに対して認証できるという事実だけでは、どちらの疑問も解決されません。
成功した計画では、レコードの差分、承認、および変更後の検証要件が保持されます。架空のシナリオは、でっち上げられたグリーンチェックではなく、その計画で終わります。これは、自動化が便利である一方、具体的なDNSと権限の効果について責任あるレビューが必要である理由を示しています。
証拠と公開状況
カタログには、ドメインの検証、権限、提案された正確な記録、および信頼できる変更後の証拠が必要です。それらの運用成果物はここには収集されていません。保持されているソースは、バージョン スコープのワークフローの議論をサポートしていますが、実際のプロバイダーのサポート、アカウントのスコープ、および実行は未検証のままです。
All six release gates remain open. DNS変更、アカウントのサインイン、トークンの作成、テンプレートのアプリケーション、またはメッセージのテストは行われませんでした。運用公開の前に、資格のあるレビュー担当者が特定の統合バージョンを確認し、実際の承認および検証成果物を検査する必要があります。その証拠が存在するまで、論文は提案されたレビュー方法のままでなければなりません。