SPF仕様の10 DNSルックアップ制限は通常適用されますか？
私の理解では、SPF仕様では、送信者に許可されているすべてのIPを収集するために、電子メールの受信者が10を超えるDNSルックアップを実行する必要はないことを指定しています。したがって、SPFレコードにinclude:foo.com include:bar.com include:baz.comとこれらの3つのドメインにはそれぞれSPFレコードがあり、これにも3つのincludeエントリがあります。これで、最大3 + 3 + 3 + 3 = 12 DNSルックアップになります。
上記の私の理解は正しいですか？
ドメインで2つまたは3つのサービスのみを使用しており、すでにこの制限をはるかに超えています。この制限は、メジャー（またはマイナー）の電子メールプロバイダーによって通常（またはこれまで）実施されていますか？
_libspf2_ （C）および _Mail::SPF::Query_ （Perl、sendmail-spf-milter）10の制限を実装するDNSの原因となるメカニズム、ただし後者は（AFAICT）MXまたはPTRの制限を適用しない。 _libspf2_は、mxおよびptrのそれぞれを10に制限します。
_Mail::SPF_ （Perl）には、DNSを引き起こすメカニズムが10個、メカニズムごと、MXごと、およびPTRごとのルックアップが10個という制限があります。 （2つのPerlパッケージは、デフォルトではありませんが、一般的にMIMEDefangで使用されます。）
pyspf は、「検索」、MX、PTR、CNAMEのすべてで10の制限があります。 but操作中に、MAX_LOOKUPSに4を明示的に乗算します。 「strict」モードでない限り、MAX_MXとMAX_PTRを4倍にします。
私は商用/独自の実装についてコメントすることはできませんが、上記の（pyspfを除く）は明らかに10のDNSトリガーメカニズムの上限を実装しています（詳細は以下を参照）、ほとんどの場合、実行時にオーバーライドできます。 -時間。
あなたが正しい特定のケースでは、それは12インクルードであり、それは10の制限を超えています。ほとんどのSPFソフトウェアは「PermError」を返すことを期待しますただし、カウントは現在の合計として計算されるため、エラーは最後の「含まれる」プロバイダーにのみ影響します。SPF メカニズムは左から右に評価されます で、チェックは「早期に」行われますパスの場合、送信サーバーが出現する順序によって異なります。
これを回避する方法は、DNSルックアップをトリガーしないメカニズムを使用することです。 _ip4_および_ip6_を使用し、可能であればmxを使用します。これにより、さらに10個までの名前を取得でき、それぞれに複数のIPを設定できます。
SPFは潜在的に指数関数的なスケーリングを伴う任意のDNSリクエストをもたらすため、DOS /増幅攻撃に簡単に悪用される可能性があります。これを回避するために意図的に低い制限があります。それはあなたが望むようにスケーリングしません。
10メカニズム（厳密にメカニズム+「リダイレクト」修飾子）原因ただし、DNSルックアップは10 DNSルックアップとまったく同じではありません。 「DNSルックアップ」の解釈は自由ですが、事前に必要な個別のルックアップの数がわからず、再帰リゾルバが実行する必要のある個別のルックアップの数が不明です（以下を参照）。
SPF実装は、DNSルックアップを行うメカニズムと修飾子の数を、SPFチェックごとに最大で10に制限する必要があります。これには、「インクルード」メカニズムまたは「リダイレクト」修飾子の使用によって引き起こされるルックアップも含まれます。チェック中にこの数を超えた場合は、PermErrorを返す必要があります。 "include"、 "a"、 "mx"、 "ptr"、および "exists"メカニズムと、 "redirect"修飾子は、この制限にカウントされます。 「all」、「ip4」、および「ip6」メカニズムはDNSルックアップを必要としないため、この制限にはカウントされません。
[...]
"mx"と "ptr"メカニズム、または％{p}マクロを評価する場合、ルックアップおよびチェックされるMXまたはPTR RRは10以下に制限する必要があります。
したがって、DNSルックアップをトリガーするメカニズム/修飾子を最大10個使用できます。 （ここでの言い回しは不適切です。制限の上限のみを示しているようです。確認の実装には2の制限がある可能性があります。）
mxメカニズムの場合は5.4、ptrメカニズムの場合は§5.5それぞれ、その種類の名前のルックアップは10回に制限されており、そのメカニズムの処理にのみ適用されます。例：
サービス拒否（DoS）攻撃を防ぐために、「mx」メカニズムの評価中に10を超えるMX名を検索してはなりません（セクション10を参照）。
つまり、最大10個のMX名を持つ10個のmxメカニズムがあり、それぞれが20個のDNSオペレーション（それぞれ10個のMX + 10 A DNSルックアップ）を合計200で発生させる可能性があります。これはptrまたは％{p}、10を検索できますptr メカニズム、つまり10x10 PTR。各PTRにもAルックアップが必要で、これも合計200です。
これは 2009.10テストスイート がチェックするものとまったく同じです。「Processing Limits」テストを参照してください。
totalSPFチェックごとのクライアントDNSルックアップ操作の数に明確な上限はありません。暗黙的に210として計算し、与えるか、または受け取ります。 SPFチェックごとのDNSデータの量を制限する提案もありますが、実際の制限は提案されていません。 SPFレコードは450バイト（他のすべてのTXTレコード）と悲しいことに共有されている）に制限されているため、大まかな見積もりを取得できますが、寛大な場合、合計が100kiBを超える可能性があります。これらの値は両方とも増幅攻撃としての潜在的な乱用に対して明らかに開放的であり、これはまさに§10.1が回避する必要があると述べていることです。
経験的証拠は、totalの10のルックアップメカニズムがレコードに一般的に実装されていることを示唆しています（Microsoft.comのSPFを確認してください。正確に10に保ちます）。必須のエラーコードは単に「PermError」であり、あらゆる種類の問題をカバーするため、多すぎる検索の失敗の証拠を収集することは困難です（ [〜＃〜] dmarc [〜＃〜] レポートはそれでも助けてください）。
OpenSPF FAQ perpetuates the limit of the total of 10 DNS lookups "、ではなく、より正確な" 10 DNS原因メカニズムまたはリダイレクト "。これはFAQそれは実際に言っているので間違いなく間違いです：
SPFレコードごとに10のDNSルックアップの制限があるため、IPアドレスを指定します[...]
これは、「SPFチェック」操作に制限を課すRFCとは一致せず、この方法でDNSルックアップ操作を制限せず、 SPFレコード が単一のDNSテキストRRであることを明確に述べています。 FAQは、 "include"を処理するときにカウントを再開することを意味します。これは、新しいSPFレコードであるためです。
DNSルックアップ
とにかく「DNSルックアップ」とは何ですか？ userとして。 「_ping www.Microsoft.com_」には単一のDNS「ルックアップ」が含まれると考えます。1つのIPに変わると予想される名前が1つあります。簡単？残念ながらそうではありません。
管理者として、www.Microsoft.comは単一のIPを持つ単純なAレコードではなく、CNAMEである可能性があることを知っています。 Aレコードを取得するための別の個別のルックアップ。ただし、私のデスクトップのリゾルバーではなく、上流のリゾルバーがおそらく実行するものです。今日、私にとって、www.Microsoft.comは3つのCNAMEのチェーンであり、最終的にはakamaiedge.netでAレコードになり、それは（少なくとも）4つのDNSクエリ操作です。 SPFは「ptr」メカニズムを備えたCNAMEを参照できますが、MXレコードはCNAMEであってはなりません。
最後に、DNS管理者として、ほとんどすべての質問への回答には、多くの個別のDNS操作、個々の質問、および回答トランザクション（UDPデータグラム）が含まれることを知っています。空のキャッシュの場合、再帰リゾルバはDNSルートから開始し、その下に向かって進む必要があります：_._→com→_Microsoft.com_→_www.Microsoft.com_特定のタイプのレコード（NS、Aなど） ）必要に応じて、CNAMEを処理します。これは実際に_Dig +trace www.Microsoft.com_で確認できますが、地理位置情報のトリック（例 here ）のため、まったく同じ答えは得られません。 （TXTレコードでSPFが便乗しているため、DNSの回答の512バイトという制限が廃止されたことにより、TCP経由でクエリを再試行する可能性があるため、この複雑さに少しでも触れてください。）
それでは、SPFはルックアップとして何を考慮しますか？ administratorの観点に最も近いので、各タイプのDNSクエリの詳細に注意する必要があります（ただし、実際には、個々のDNSデータグラムまたは接続をカウントする必要があります）。
RFC4408 s10.1 は、ご指摘のとおり、DNSアクティビティにいくつかの制限を課します。具体的には：
SPF実装は、DNSルックアップを行うメカニズムと修飾子の数を、SPFチェックごとに最大で10に制限する必要があります。これには、「インクルード」メカニズムまたは「リダイレクト」修飾子の使用によって引き起こされるルックアップも含まれます。チェック中にこの数を超えた場合は、PermErrorを返す必要があります。 "include"、 "a"、 "mx"、 "ptr"、および "exists"メカニズムと、 "redirect"修飾子は、この制限にカウントされます。 「all」、「ip4」、および「ip6」メカニズムはDNSルックアップを必要としないため、この制限にはカウントされません。説明文字列をフェッチするDNSルックアップは、SPFレコードが評価された後に行われるため、「exp」修飾子はこの制限にカウントされません。
そして更に
"mx"と "ptr"メカニズム、または％{p}マクロを評価する場合、ルックアップおよびチェックされるMXまたはPTR RRは10以下に制限する必要があります。
前者はメカニズムの数の制限であり、実行されるルックアップの数ではないことに注意してください。しかし、それはまだ限界です。
私の知る限り、そうです、これらの制限はかなり厳しく強制されています。これらは、任意に複雑なSPFレコードを作成し、それらを使用して、DNSルックアップの巨大なチェーンで停止するまでレコードをチェックするDoSサーバーにそれらを使用することを阻止するように設計されています。それらを尊重します。
ネストされたインクルードは、これらの制限で最大の問題を引き起こす可能性が高いことに注意してください。それぞれがインクルード自体を頻繁に使用する複数のドメインを含めることを決定した場合、かなり迅速にそれらを超えることができます。見つけるのはそれほど難しくありません これにより具体的な問題が発生した人の例 。
結局のところ、人々がboth SPF andを使用して送信メールを処理することを決定した場合、問題が一般的に発生するようです。あなたの質問から、あなたはそのカテゴリーに当てはまると思います。 SPFは、これを行うことを選択した人々にサービスを提供するようには設計されていないようです。これを行うと主張する場合は、DNSサーバーで何らかのcronジョブを実行して、含めたいすべてのSPFレコードを常に評価し、それらを一連の_ip4:_および_ip6:_メカニズム（数に制限はありません）、SPFレコードとして結果を再公開します。
_-all_で終了することを忘れないでください。そうしないと、演習全体が無意味でした。