コンテンツ配信は、FCrDNS（前方確認された逆引きDNS）ルックアップに依存する必要がありますか？その理由は？

Question

まず、これが DNSサーバーからの意図的に間違った情報が一般に認められている標準に違反していないか]の複製ではないことを明確にしますスレッド、I'm法的な側面やDNSの基準、ISPのベストプラクティスに興味がない。現時点では私の関心事ではありません。テクニック、それは私があなたに尋ねたいことについての多くの洞察を提供しません。これは私に私の質問をもたらします：

私が知りたいのは、フォワードDNSルックアップテーブルに含まれていないクライアントへのWebサーバー要求（および要求されたコンテンツの配信）のブロックに関するあなたの意見です。発信元IPを要求します。または、別の言い方をすれば、クライアントが失敗する転送確認済みの逆引きDNS チェック。

私の見たところ、DNSチェックの転送に失敗するクライアントには3つの異なるカテゴリがあります。

存在しないDNS PTR。これらは、フォワードDNSルックアップを実行するときに私のSocksライブラリで0.0.0.0のIPに解決し、ほとんどのIPv6クライアントがIPv4ブローカーを介してトンネリングする仲介者が含まれるクライアントですIPv4 PTRは無意味であり、DNSレコードが（意図的またはその他の方法で）誤って構成されているIPv4クライアント。私のライブラリはお互いを区別することができ、IPv4ブローカーを介してリクエストを送信するIPv6クライアントをブロックするつもりはありません。後者についてはよくわかりませんが、それらについてのご意見をいただければ幸いです。
AAAレコードを指すレコード、またはその逆。これらは、セキュリティ上の理由、VPNまたはプロキシの設定など、意図的に誤ってDNSレコードが構成されている可能性があるクライアントですが、同じASNに解決されます。たとえば、1.2.3.4のIPには名前crawler.someserver.xxxがありますが、この名前はフォワードDNSルックで解決されます-（r/DNS）someserver.xxxという名前のIP1.2.3.5までで、両方のIPが同じASNの一部である。リクエストごとに非常に多くのDNSレコードをチェックするには少しコストがかかりますが、結果をキャッシュし、ローカルの定期的に更新されるデータベースを介してIANA登録ASN範囲をクエリすることもできます。そのようなクライアントは、私に関する限り許容できますが、念のため、より頻繁にリクエストが調査されるようになります。
スプーフィングされたDNSレコード。これらのクライアントは私の最大の関心事であり、私の質問の主な理由です。それらには、フォワードDNSチェックに完全に失敗し、PTRがASN範囲外のIPを返し、r-DNSルックアップが互いにリモートに似ていない（または、割り当てられた名前。これもよくあることです）。正直なところ、私はこれらのタイプに同情することはできません。これらのタイプが表示されたらすぐにブロックすることを再検討する必要がある理由があると思われる場合は、お知らせください。

私は現在、そのようなクライアントのテストがポリシーに含まれていないサービスを実行していますが、これまでに一部のクライアントに対して手動で特定のブロックを実施しています。これらのクライアント（FCrDNSテストに失敗したもの）はすべて、私のTOSへのその他の違反のためにブラックリストに登録されており、私はまだサービスの正当な使用を確認していませんFCrDNSテストに失敗し、DNSレコードを偽装するクライアント。

たとえば、私が強制しているそのようなブロックの1つは、nlnd02.xsltel.comに解決されるIP93.174.93.52にあります。前方参照テーブルには、r-DNSを使用して解決しない76.72.171.131のIPのみが含まれています。 93.174.93.52のこのIPは、HTTP Proxyプローブのブラックリストにリストされており、現在、他のいくつかのハニーポット（AHBLおよびUCEPROTECT）にもリストされていますが、IP76.72.171.131は、FCrDNSテストを使用することで解決されることを示していますが、一部のハニーポットではDNSの問題が報告されています。このことから、特定のハニーポットによる検出を回避するために、このクライアントはDNSレコードを意図的にマスクしていると収集しました。

私の質問は、DNSrecordsをマスキングするための合法的な使用があるか、またはそのような着信を自動的にブロックするようにWebアプリケーションサービスを更新する必要があると思いますトラフィック（コンテンツ配信の観点から）を確認し、それに応じてTOSを変更します。そのようなテストの技術的な実装は問題ではありません、または少なくとも私が認識していない他の法的問題はありません。当てはまる可能性のあるものを考えることができれば、遠慮なくそれらについて言及してください。

これらのFCrDNSチェックは、/ Webアプリケーションレベルで実装されます。それらは唯一のセキュリティ対策ではないので、低レベルのチェックへの追記と考えてください。主にコンテンツの廃棄者、フォーラムのスパマーを阻止するための入札で、および同様のネットワークの糞がトラックで死んでいます。

さらに、/任意のTOSの例があり、そのようなフィルターとその背後にある理由が適切に記述されている場合は、さらに優れています。

あなたのすべての貢献を事前に感謝します！

Tom Leek · Accepted Answer

リバースDNSなしでIPをブロックすることは、ISPが悪い人を罰することを意味します。ほとんどのISPはリバースDNSを設定する必要があることを理解しているようですが、時折事故が発生します。私の知る限りでは、リバースDNSを実装しない「正当な」理由はありませんが、それが頻繁に発生し、そのような要求を拒否することは厳しいようであり、適切な教育的効果を必要とすることもほとんどありません。

また、IPv6の場合、（マシンのMACアドレスから計算された）自動的に割り当てられたアドレスでは、欠落しているリバースDNSが標準である可能性が高いことにも注意してください。

Jacob Evans · Answer

FCrDNSは、エンドユーザーがドメインまたは組織で自分自身を正しく識別する必要がある場合にのみ必要です。一般的に、送信元アドレスヘッダーが送信IP（IPv4またはIPv6アドレス）のPTRと一致する必要がある電子メールに使用されます。

実際、トムは、GoogleがIPv6で開始された電子メール接続に適切なRDNSを要求していることに気付いた場合、それは不可能です。企業がRDNSを要求できない唯一の理由は、本番環境で確立された、誤設定されたシステムが多すぎることです。 -all spfメカニズムでも同じことが言えます。これは、誤って構成されたシステムの過剰です。

送信IPにはPTRレコード（つまり、送信IPの逆引きDNS）が必要であり、PTRレコードで指定されたホスト名の正引きDNS解決を介して取得したIPと一致する必要があります。それ以外の場合、メールはスパムとしてマークされるか、場合によっては拒否されます。 - 出典Google

私たちは、UCEBLやRFC無視などのブラックリストを使用しようとしましたが、結果としてスパムが少なくなり、エンドユーザーを怒らせ、サードパーティは嫌がらせています。