正引きで確認された逆引きDNSエントリ

 

Forward-confirmed reverse DNS（FCrDNS）、またはfull-circle reverse DNS、double-reverse DNS、iprevとしても知られるこのネットワークパラメータの設定は、特定のIPアドレスが前方（名前からアドレスへ）と後方（アドレスから名前へ）の両方向のドメイン名システム（DNS）エントリーを持ち、お互いに一致している状態を指す。 これは、多くのDNS依存プロトコルを支援するインターネット標準によって期待される標準的な設定である。

デビッド・バーはRFC 1912（情報提供）で、DNS管理者に対してこれをベストプラクティスとして推奨する意見を発表したが、DNS標準自体にはこれに関する正式な要件は組み込まれていない。

FCrDNS検証は、ドメイン名の所有者とIPアドレスが割り当てられたネットワークの所有者との間に有効な関係があることを示す、弱い形の認証を作成することができる。 この認証は弱いが、スパマーやフィッシャーがメールのスプーフィングにゾンビコンピュータを使用する際、通常はこの検証をバイパスすることができないため、ホワイトリストの目的で使用するのに十分な強さがある。

つまり、逆DNSは検証されるかもしれないが、通常は主張されたドメイン名とは別のドメインの一部であることが多い。

ISPのメールサーバをリレーとして使用することで、逆DNSの問題を解決することができる。 送信リレーの前方および後方ルックアップが一致する必要があるため、それがメッセージが中継するfromフィールドや送信ドメインと関連している必要はない。

メールでIPアドレスとドメインの関係を確立する他の方法には、Sender Policy Framework（SPF）とMXレコードがある。

逆DNSを設定しない、または設定できないISPは、逆DNSが対応するA（またはAAAA）レコードと一致する必要があるアプリケーションやプロトコルをサポートできないため、ネットワーク上のホストに問題を引き起こす。 逆DNSを提供できない、または提供しないISPは、最終的にはクライアントベースが提供するインターネットサービスを効果的かつ安全に使用する能力を制限されることになる。

適用

• 多くのメール転送エージェント（サーバソフトウェア）は、FCrDNS検証を使用し、有効なドメイン名がある場合は、それを「Received:」トレースヘッダフィールドに記入する。
• 一部のメール転送エージェント (サーバソフトウェア) は、SMTP HELOおよびEHLOコマンドで与えられたドメイン名に対してFCrDNS検証を行う。これはRFC 2821に違反する可能性があるため、通常はデフォルトで電子メールは拒否されない。
• Sender Policy Frameworkの電子メール偽造防止システムは、その「ptr:」メカニズムでFCrDNS検証を使用する。 しかし、この「ptr:」メカニズムの使用は、2006年のSPFの最初の標準化（RFC 4408）以来、奨励されていない。
• 一部のe-mail spamフィルターは、RFC 8601に従って、ドメイン名の認証方法またはホワイトリストの目的でFCrDNS検証を使用する。
• SpamCop FCrDNS検証を使用するが、これは、適切に一致するDNSとrDNSレコードを提供しないインターネットサービスプロバイダの顧客であるSpamCopユーザーに時々問題を引き起こす。 [1] [2]
• 一部のFTP、Telnet、TCP WrapperサーバはFCrDNS検証を実行する。[3]
• 一部のIRCサーバは悪用を防ぐためにFCrDNS検証を実行する。