逆引き検索では、IP アドレスの要求されたホスト名が返されます。転送確認済み 逆引きDNS 次に、そのホスト名が元のアドレスに解決されるかどうかを確認します。 2 番目のステップでは、一般的な不一致を検出しますが、一致によって、送信者が信頼できるか、メッセージの From ドメインの使用を許可されているかは確立されません。
比較を定義する
参考文献: RFC 1912 §2.1, RFC 3596 §2.1, RFC 4291 §2.2.
開始値として、観察されたSMTP送信元アドレスを取得します。 PTRレコードをクエリします。返されたホスト名ごとに、適切な転送アドレス タイプ ( IPv4ソースの場合は A、 IPv6ソースの場合は AAAA) をクエリします。 IPv6用の IP パーサーを使用してアドレス値を比較し、同等のテキスト形式が同様に扱われるようにします。
このガイドの診断の場合、確認とは、返されたホスト名の転送アドレス セットの少なくとも 1 つに元の IP が含まれていることを意味します。ホストごとの結果とその概要を保存します。これは明示的に定義された診断ルールであり、すべての受信者が同じ選択ポリシーを実装したり、すべてのPTR結果をチェックしたりすることを約束するものではありません。
失敗を明確に区別する
参考文献: RFC 1035 §4.1.1, RFC 2181 §10.2.
PTR応答がない、一致するアドレスがないホスト名、 DNSタイムアウト、および検証の失敗は、異なる結果です。タイムアウトはレコードが存在しないことを証明できません。 IPv4 A の一致では、 IPv6ソースの確認は確立されません。すべての結果を単一の赤いバッジにまとめるのではなく、応答コードとタイミングを保持します。
ホスト名に対して返された最初のアドレスで停止しないでください。ホストは複数のアドレスを持つことができ、元のアドレスはセットの後半にある可能性があります。また、ダッシュボードが複数のPTR名を黙って破棄すべきではありません。何が一致したかを正確に説明するには、基礎となる結果が必要です。
合成テストセットを計算する
ケース A は次から始まります 192.0.2.25。 PTRリターン smtp.example.com;その名前のAセットは 192.0.2.24, 192.0.2.25。元のアドレスはセットのメンバーであるため、期待された結果が確認されます。セット全体との同等性は必要ありません。
ケース B は同じPTRを使用しますが、A セットには 192.0.2.24。期待される結果は不一致です。ケース C は、前方参照でタイムアウトを受け取ります。期待された結果は不一致ではなく、未解決です。ケース D は次から始まります 2001:db8::25 そしてターゲットのAAAAの答えは 2001:0db8:0000:0000:0000:0000:0000:0025。両方をIPv6アドレスとして正規化すると、期待した結果が確認されます。
フィクスチャ リゾルバまたは分離ゾーンを使用して、これらのケースを再現します。ケースごとに、ソース IP、 PTR応答、転送応答、クエリ タイプ、および計算されたメンバーシップ結果を保存します。単純な実装では、メンバーシップ ステップの前にDNSエラーを処理しながら、各アドレスを解析し、ソースが返されたセットに含まれるかどうかを評価します。これらの予想される結果は、製品版受信機がテストされたことを主張するものではありません。
オーナー側の不一致を修復する
参考文献: RFC 1035 §3.5, RFC 8767 §4.
PTRが間違っている場合は、リバース ゾーン オペレータと協力してください。転送アドレスが間違っている場合は、ホスト名の権限のあるDNSオペレーターと協力してください。どちらも権限では正しいが、リゾルバーでは正しくない場合は、キャッシュまたは異なるビューを調査してください。連続した変更が永続的な不一致として誤診されないように、両方の方向の証拠を同時に保管してください。
最後に、実際のSMTPルートをテストし、受信者の応答を保持します。転送確認は、 DNSデータの一貫性のプロパティです。攻撃者は、一致する順方向および逆方向のレコードを操作することができ、正規のプロバイダーは依然として構成が壊れている可能性があります。この調査結果を、認証や悪用の制御の代わりにではなく、並行して使用します。
証拠の範囲を明示的に保つ
4 つの合成ケース (確認済み、不一致、未解決、確認済み) は、アドレス メンバーシップと正規化だけでチェックできます。ローカル計算では、 PTRや前方参照、受信機の実行、または評判の測定は実行されません。