我的理解是 SPF 规范指定电子邮件接收者不应进行 10 次以上的 DNS 查找，以便为发件人收集所有允许的 IP。因此，如果一个 SPF 记录有include:foo.com include:bar.com include:baz.com并且这三个域每个都有 SPF 记录并且也有 3include个条目，那么现在我们最多可以进行 3+3+3+3=12 个 DNS 查找。
我上面的理解正确吗？
我只为我的域使用 2 或 3 个服务，而且我已经超过了这个限制。主要/次要电子邮件提供商通常（或曾经）强制执行此限制吗？
mr.*_*tic 31
两个libspf2（C）和Mail::SPF::Query（Perl中，在所使用的sendmail-SPF-雄鱼）实现的10的限制DNS-引起机制，但后者不（AFAICT）应用MX或PTR限制。libspf2也将mx和ptr 中的每一个限制为 10。
Mail::SPF(perl) 限制为 10 个 DNS 导致机制，每个机制、每个 MX 和每个 PTR 限制为 10 个查找。（这两个 perl 包通常在MIMEDefang 中使用，但不是默认使用。）
pyspf对所有以下内容的限制为 10：“查找”、MX、PTR、CNAME；但它在操作期间显式地将 MAX_LOOKUPS 乘以 4。除非在“严格”模式下，它还会将 MAX_MX 和 MAX_PTR 乘以 4。
我无法评论商业/专有实现，但上述（除了pyspf）明确实现了 10 个 DNS 触发机制的上限（更多关于下面的内容），给予或接受，尽管在大多数情况下它可以在运行时被覆盖 -时间。
在您的特定情况下，您是正确的，它是 12 个包含并且超过了 10 个的限制。我希望大多数 SPF 软件返回“PermError”，但是，失败只会影响最终的“包含”提供程序，因为计数将作为运行总数计算：从左到右评估SPF机制，检查将“提前”通过，因此这取决于发送服务器出现的顺序。
解决这个问题的方法是使用不触发 DNS 查找的机制，例如ip4和ip6，然后mx尽可能使用，因为这可以让您获得多达 10 个其他名称，每个名称可以有多个 IP。
由于 SPF 导致任意 DNS 请求具有潜在的指数缩放，因此很容易被用于 DOS/放大攻击。它故意设置低限制来防止这种情况：它不会按照您想要的方式进行扩展。
不过，导致DNS 查找的10 种机制（严格来说是机制 +“重定向”修饰符）与 10 次 DNS 查找并不完全相同。甚至“DNS 查找”也可以解释，您事先不知道需要多少个离散查找，也不知道您的递归解析器可能需要执行多少个离散查找（见下文）。
SPF 实现必须将进行 DNS 查找的机制和修饰符的数量限制为每次 SPF 检查最多 10 个，包括由使用“包含”机制或“重定向”修饰符引起的任何查找。如果在检查过程中超过了这个数字，必须返回 PermError。“include”、“a”、“mx”、“ptr”和“exists”机制以及“重定向”修饰符不计入此限制。“all”、“ip4”和“ip6”机制不需要 DNS 查找，因此不计入此限制。
[...]
在评估“mx”和“ptr”机制或 %{p} 宏时，必须有不超过 10 个 MX 或 PTR RR 查找和检查的限制。
因此，您最多可以使用 10 个触发 DNS 查找的机制/修饰符。（这里的措辞很糟糕：它似乎只说明了限制的上限，确认实现的限制可能是 2。）
第5.4节的MX机制，§5.5的PTR机制都具有的那种名字的10所查询的限制，而且仅适用于该机制，如处理：
为防止拒绝服务 (DoS) 攻击，在评估“mx”机制期间不得查找超过 10 个 MX 名称（请参阅第 10 节）。
即您可能有 10 个 mx 机制，最多有 10 个 MX 名称，因此每个可能会导致 20 个 DNS 操作（每个 10 个 MX + 10 个 DNS 查找）总共 200 个。ptr或%{p}类似，您可以查找 10 个ptr机制，因此是 10x10 个 PTR，每个 PTR 也需要 A 查找，总共 200 个。
这正是2009.10 测试套件检查的内容，请参阅“处理限制”测试。
对于每次 SPF 检查的客户端 DNS 查找操作的总数没有明确规定的上限，我将其计算为隐式 210，给予或接受。还有一个建议可以限制每次 SPF 检查的 DNS 数据量，但没有建议实际限制。您可以粗略估计，因为 SPF 记录限制为 450 字节（遗憾的是与所有其他 TXT 记录共享），但如果您慷慨，总数可能会超过 100kiB。这两个值显然都可能被滥用为放大攻击，这正是 §10.1 所说的您需要避免的。
经验证据表明，记录中通常实现了总共10 种查找机制（查看 microsoft.com 的 SPF，他们似乎竭尽全力将其保持在 10 种）。很难收集太多查找失败的证据，因为强制的错误代码只是“PermError”，它涵盖了所有问题（尽管DMARC报告可能对此有所帮助）。
OpenSPF FAQ延续了总共“10 个 DNS 查找”的限制，而不是更精确的“10 个 DNS 导致机制或重定向”。这个常见问题可以说是错误的，因为它实际上说：
由于每个 SPF 记录有 10 次 DNS 查找的限制，因此指定一个 IP 地址 [...]
这与对“SPF 检查”操作施加限制的 RFC 不一致，不以这种方式限制 DNS 查找操作，并明确指出SPF 记录是单个 DNS 文本 RR。常见问题解答暗示您在处理“包含”时重新开始计数，因为这是一个新的 SPF 记录。真是一团糟。
什么是“DNS 查找”？作为用户。我认为“ ping www.microsoft.com”涉及单个 DNS“查找”：我希望将一个名称变成一个 IP。简单的？可惜不是。
作为管理员，我知道 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，但由于地理定位技巧，您可能不会得到完全相同的答案（此处的示例）。（由于 SPF 搭载在 TXT 记录上，因此这种复杂性还有一点点，而且 DNS 答案上 512 字节的过时限制可能意味着通过 TCP 重试查询。）
那么 SPF 将什么视为查找？它真的最接近管理员的观点，它需要了解每种类型的 DNS 查询的细节（但不是实际需要计算单个 DNS 数据报或连接的地步）。
Mad*_*ter 11
正如您所指出的，RFC4408 s10.1确实对 DNS 活动设置了一些限制。具体来说：
SPF 实现必须将进行 DNS 查找的机制和修饰符的数量限制为每次 SPF 检查最多 10 个，包括由使用“包含”机制或“重定向”修饰符引起的任何查找。如果在检查过程中超过了这个数字，必须返回 PermError。“include”、“a”、“mx”、“ptr”和“exists”机制以及“重定向”修饰符不计入此限制。“all”、“ip4”和“ip6”机制不需要 DNS 查找，因此不计入此限制。“exp”修饰符不计入此限制，因为获取解释字符串的 DNS 查找发生在评估 SPF 记录之后。
而且
在评估“mx”和“ptr”机制或 %{p} 宏时，必须有不超过 10 个 MX 或 PTR RR 查找和检查的限制。
请注意，前者是对机制数量的限制，而不是执行的查找次数；但这仍然是一个限制。
据我所知，是的，这些限制执行得相当严格。它们旨在阻止人们构建任意复杂的 SPF 记录，并将这些记录用于检查记录的 DoS 服务器，方法是在庞大的 DNS 查找链中停止它们，因此这符合任何实施 SPF 检查器的人的最佳利益尊重他们。
您注意到嵌套包含可能会导致这些限制的最大问题是正确的，如果您决定包含多个域，每个域都大量使用包含本身，那么您可以相当快速地检查它们。不难找到这为他们带来具体问题的人的例子。
其结果似乎是，当人们决定使用问题一般出现两个SPF
和若干独特的，不同的公司来处理他们传出的电子邮件。我从您的问题中推断您属于该类别。 SPF 似乎并非旨在为选择这样做的人提供服务。如果您坚持这样做，您可能需要在您的 DNS 服务器上进行某种 cron 作业，不断评估您希望包含的所有 SPF 记录，将它们表示为一系列ip4:和ip6:机制（关于其中的数量）没有限制），并将结果重新发布为您的 SPF 记录。
不要忘记以 结束-all，否则整个练习毫无意义。
| 归档时间： |
|
| 查看次数： |
26097 次 |
| 最近记录： |