A および AAAA レコードは、ホスト名をIPv4およびIPv6アドレスにマップします。これらはメール サービスの依存関係であり、サービスが送信の準備ができている、または送信を許可されているという宣言ではありません。アドレスを公開すると、クライアントが実際に試行するルートが公開される可能性があるため、公開されたすべてのファミリとエンドポイントを確認します。
プロトコルで使用される名前に従ってください
参考文献: RFC 5321 §5.1, RFC 7208 §5.3, RFC 7208 §5.4.
インバウンドSMTPの場合は、 MXから返された交換ホスト名を解決します。明示的な交換が使用できない場合、受信者ドメインの Web サイト アドレスは代わりにはなりません。 MX存在しない場合、 SMTPの暗黙的 MX ルールにより、代わりに受信者ドメイン独自の A または AAAA レコードが関連するようになります。
アウトバウンド向け SPF、実際のポリシーと評価されたアイデンティティを調べます。アン a メカニズムは、指定された名前に対して返されるアドレスを承認できます。平野 記録 それ自体では何も許可されません。同様に、 SPFで使用されるホスト名の変更 MX このメカニズムは、許可されていると評価されたアドレスを変更できます。 DNSアドレスの編集を Web サイトのみの変更として扱う前に、これらの参照を記録してください。
デュアルスタックを 2 つの動作パスとして扱う
参考文献: RFC 1035 §3.4.1, RFC 3596 §2.1, RFC 3596 §2.3.
ホスト名には、複数の A レコードと複数の AAAA レコードを含めることができます。これらの存在は、到達可能性、 SMTPサービス、正しい証明書、または同等のポリシーを保証するものではありません。正常なIPv4エンドポイントは、 IPv6が機能することを確立しません。逆に、1 つのクライアント パスで障害が発生しても、すべての送信者がそのパスを使用していることは証明されません。
実際に試行された宛先アドレス、アドレス ファミリ、接続結果、およびSMTP応答をキャプチャします。送信トラフィックを調査する場合は、アプリケーション内で使用されているアドレスと一致すると仮定するのではなく、外部で観測された送信元アドレスを取得します。 NAT およびプロバイダー出力プールによって、これらの値が異なる場合があります。
アドレスファミリー障害を再現する
合成治具: example.com. MX 10 mx.example.com.; mx.example.com. A 192.0.2.10; mx.example.com 。 AAA 2001:db8::10。ラボでは、ポート 25 で TCP 接続を受け入れ、 IPv6エンドポイントを到達不能のままにするようにIPv4エンドポイントを構成します。予期されたDNSチェックは両方のレコード タイプで成功しますが、ファミリ固有の接続テストはIPv4でのみ成功します。
クエリ @AUTH mx.example.comを掘ります。 +norecurse そして同じコマンドを実行します AAAA。 AUTH を分離された権限に置き換えます。両方の回答を記録します。承認されたラボSMTPクライアントを使用して、各宛先を個別に固定し、接続とプロトコルの結果を記録します。このフィクスチャは、 DNS成功がサービスの成功ではない理由を示しています。特定の送信者のフォールバック タイミングについては主張しません。
2 番目のフィクスチャは、A アドレスのみを変更します。 192.0.2.10 に 192.0.2.20 SPFポリシーは v=spf1 a:mx.example.com -all。ルックアップが成功した場合のIPv4 SPF評価の場合、アドレスは、 a 仕組みが変わります。明示的な ip4:192.0.2.10 代わりに、このメカニズムは、ポリシー自体が変更されるまで、文字通りのネットワークに関連付けられたままになります。
アドレス変更を元に戻せるようにする
参考文献: RFC 8767 §4.
メール ルーティング、 SPF参照、監視、証明書の期待値など、ホスト名のすべてのコンシューマをインベントリします。エンドポイントをアドバタイズする前に準備します。普遍的な待機期間ではなく実際の移行計画に基づいて、適切なキャッシュが依然としてトラフィックをそこに誘導できる間、古いサービスを保持します。
変更後、信頼できる回答を再帰的な観察およびメッセージレベルの証拠と比較します。障害が発生したIPv6エンドポイントは、無関係な認証ポリシーを弱めて隠すのではなく、承認された変更を通じて修復または削除する必要があります。意図したアドレスと操作パスが文書化されたサービス設計と一致する場合にのみ、作業を終了します。
証拠の範囲を明示的に保つ
2 つのファミリーのシナリオでは、予想されるIPv4成功とIPv6失敗を、テストされるまで提案されたラボ観察として保持します。 SPFアドレス変更の例では、ルックアップが成功し、指定されたポリシーが適用されていることを前提としています。実際の送信者に対する現在の認証は確立されません。