フォワード確認逆DNS

フォワード確認型リバース DNS ( FCrDNS ) は、フルサークル リバース DNS、ダブル リバース DNS、またはiprevとも呼ばれ、特定の IP アドレスに、互いに一致するフォワード (名前からアドレス) とリバース (アドレスから名前) の両方のドメイン ネーム システム (DNS) エントリがあるネットワーク パラメータ構成です。これは、多くの DNS 依存プロトコルをサポートするインターネット標準で期待される標準構成です。David Barr は、RFC 1912 (情報) で、DNS 管理者のベスト プラクティスとしてこれを推奨する意見を発表しましたが、DNS 標準自体には正式な要件は定められていません。^[1]

FCrDNS 検証は、ドメイン名の所有者と IP アドレスが付与されたネットワークの所有者との間に有効な関係があるという弱い形式の認証を作成できます。この認証は弱いものの、スパム送信者やフィッシング詐欺師がゾンビ コンピュータを使用して電子メールを偽装する際にこの検証を回避できないため、ホワイトリストの目的に使用できるほど強力です。つまり、逆 DNS は検証できますが、通常は要求されたドメイン名とは別のドメインの一部になります。

ISP のメール サーバーをリレーとして使用すると、逆 DNS の問題を解決できる場合があります。これは、送信リレーの順方向検索と逆方向検索が一致する必要があるという要件があり、リレーするメッセージの送信元フィールドや送信ドメインに関連付けられている必要がないためです。

電子メール内の IP アドレスとドメインの関係を確立する他の方法としては、Sender Policy Framework (SPF) とMX レコードがあります。

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

• ほとんどの電子メールのメール転送エージェント(サーバー ソフトウェア) は FCrDNS 検証を使用し、有効なドメイン名がある場合は、それを「Received:」トレース ヘッダー フィールドに格納します。
• 一部の電子メールのメール転送エージェントは、SMTP HELO および EHLO コマンドで指定されたドメイン名に対して FCrDNS 検証を実行します。これは RFC 2821 に違反する可能性があるため、電子メールは通常、デフォルトでは拒否されません。
• Sender Policy Framework の電子メール偽造防止システムでは、"ptr:" メカニズムで FCrDNS チェックを使用します。ただし、この "ptr:" メカニズムの使用は、2006 年の SPF の最初の標準化 (RFC 4408) 以降は推奨されていません。
• たとえば、一部の電子メール スパムフィルターでは、RFC 8601 に従って、ドメイン名の認証方法やホワイトリスト作成の目的で FCrDNS チェックを使用します。
• SpamCopはFCrDNSチェックを使用するため、メールサーバーに適切に一致するDNSおよびrDNSレコードを提供しないインターネットサービスプロバイダーの顧客でもあるSpamCopユーザーには問題が発生することがあります。[1] [2]
• 一部のFTP、Telnet、TCP WrapperサーバーはFCrDNSチェックを実行します。[3] 2020年7月1日にWayback Machineにアーカイブされました。
• 一部のIRCサーバーは、不正使用を防ぐために FCrDNS チェックを実行します。