我的理解是,SPF规范指定一个电子邮件接收者不应该做超过10个DNS查找,才能收集发件人所有允许的IP地址。 因此,如果SPFlogginginclude:foo.com include:bar.com include:baz.com
,这三个域都有SPFlogging,其中也有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)具有10个DNS引起机制的限制,并且每个机制,每个MX和每个PTR限制10个查找。 (这两个perl包通常在MIMEDefang中使用,但不是默认的。
pyspf
对所有的“查找”,MX,PTR,CNAME都有10个限制。 但在操作过程中它明确地将MAX_LOOKUPS乘以4。 除非在“严格”模式下,它也将MAX_MX和MAX_PTR乘以4。
我不能评论商业/专有实现,但上面( pyspf
除外)清楚地实现了10个DNS触发机制的上限(下面更多),但是在大多数情况下,它可以在运行时被覆盖-时间。
在你的具体情况下,你是正确的,它是12包括,超过了10的限制。我希望大多数SPF软件返回“PermError”, 但是 ,失败只会影响最终的“包含”提供商(S),因为计数将作为运行总数来计算:SPF 机制从左到右进行评估,并且检查将在通过时“提前”,因此取决于发送服务器出现在序列中的哪个位置。
解决这个问题的方法是使用不触发DNS查找的机制,例如ip4
和ip6
,然后在可能的情况下使用mx
,因为这样可以获得多达10个其他名称,每个名称可以有多个IP。
由于SPF会导致任意的DNS请求,并可能以指数级别进行扩展,所以很容易被DOS /放大攻击利用。 它有故意的低限制来防止这种情况发生:它没有按照你想要的方式扩展。
导致 DNS查询的10个机制(严格的机制+“redirect”修改器)与10个DNS查找并不完全一样。 即使“DNS查找”也是可以解释的,事先并不知道需要多less次离散查询,而且您也不知道recursionparsing器可能需要执行多less次离散查找(请参见下文)。
RFC 4408§10.1 :
SPF实现必须将执行DNS查找的机制和修饰符的数量限制在每个SPF检查至多10次,包括使用“包含”机制或“redirect”修改器引起的任何查找。 如果在检查过程中超过这个数字,则必须返回一个PermError。 “包含”,“a”,“mx”,“ptr”和“存在”机制以及“redirect”修饰符都会计入此限制。 “全部”,“ip4”和“ip6”机制不需要DNS查找,因此不计入此限制。
[…]
在评估“mx”和“ptr”机制或%{p}macros时,必须限制不超过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机制,因此10×10个PTR,每个PTR也需要一个A查找,总共200个。
这正是2009.10testing套件检查的内容,请参阅“ 处理限制 ”testing。
每个SPF检查的客户端DNS查询操作总数没有明确规定的上限,我将其计算为210。 也有build议限制每个SPF检查的DNS数据量,虽然没有提出实际的限制。 由于SPFlogging限制在450字节(与所有其他TXTlogging共享),所以可以粗略估计,但如果您慷慨,则总数可能会超过100 KB。 这两个值都明显地对潜在的滥用开放,作为放大攻击,这正是§10.1所说的你需要避免的。
经validation据表明, 共有 10个查找机制通常在logging中实现(请查看microsoft.com的SPF,他们似乎已经花费了一些时间将其保留到10)。 很难收集太多查找失败的证据,因为强制的错误代码只是“PermError”,它涵盖了所有的问题( DMARC报告可能有帮助)。
OpenSPF常见问题永远延续了 “10个DNS查找”的限制,而不是更精确的“10个DNS引起的机制或redirect”。 这个FAQ可以说是错的,因为它实际上是这样说的:
由于每个SPFlogging有10个DNS查询的限制,因此指定一个IP地址[…]
与RFC中对“SPF检查”操作施加限制的RFC不一致,不以这种方式限制DNS查找操作,并且明确指出SPFlogging是单个DNS文本RR。 常见问题将暗示您在处理“包含”时重新启动计数,因为这是新的SPFlogging。 真是一团糟。
什么是“DNS查询”呢? 作为用户 。 我会考虑“ ping www.microsoft.com
”涉及一个单一的DNS“查找”:有一个名字,我希望变成一个IP。 简单? 可悲的是,
作为一名pipe理员,我知道www.microsoft.com可能不是一个简单的具有单个IP的Alogging,它可能是一个CNAME,它需要另一个离散查找来获得Alogging,尽pipe我的上游parsing器可能会执行而不是我的桌面上的parsing器。 今天,对于我来说,www.microsoft.com是一个由3个CNAME组成的链,最终成为akamaiedge.net上的Alogging,这是(至less)4个DNS查询操作。 SPF可能会使用“ptr”机制看到CNAME,但MXlogging不应该是CNAME。
最后,作为一个DNSpipe理员,我知道回答(几乎)任何问题都涉及到许多离散的DNS操作,个别的问题和回答事务(UDP数据报) – 假设一个空的caching,recursion的parsing器需要在DNS根开始,向下: .
→ com
→ microsoft.com
→ www.microsoft.com
询问特定types的logging(NS,A等),并处理CNAME。 您可以通过dig +trace www.microsoft.com
看到这个动作,但是由于地理位置欺骗(例如这里 ),您可能不会得到完全相同的答案。 (自从TXTlogging上的SPF搭载以及DNS答案中512字节的过时限制可能意味着重试TCP上的查询,这种复杂性还有一点点。
那么SPF认为什么是查找? 它最接近pipe理员的angular度,它需要知道每种types的DNS查询的具体情况(但不是实际需要计算单个DNS数据报或连接的点)。
正如您所指出的, RFC4408 s10.1会对DNS活动设置一些限制。 特别:
SPF实现必须将执行DNS查找的机制和修饰符的数量限制在每个SPF检查至多10次,包括使用“包含”机制或“redirect”修改器引起的任何查找。 如果在检查过程中超过这个数字,则必须返回一个PermError。 “包含”,“a”,“mx”,“ptr”和“存在”机制以及“redirect”修饰符都会计入此限制。 “全部”,“ip4”和“ip6”机制不需要DNS查找,因此不计入此限制。 “exp”修饰符不计入此限制,因为在查询SPFlogging后,发生解释string的DNS查找。
而且
在评估“mx”和“ptr”机制或%{p}macros时,必须限制不超过10个MX或PTR RR的查找和检查。
请注意,前者是机制数量的限制,而不是执行的查找次数; 但这仍然是一个限制。
据我所知,是的,这些限制相当困难。 它们的目的是阻止人们构build任意复杂的SPFlogging,并将这些logging用于DoS服务器,这些服务器通过在大型DNS查找链中停顿来检查其logging,因此实施SPF检查程序的任何人的最佳利益尊重他们。
你应该注意到,嵌套包含可能会导致这些限制的最大问题,如果你决定包含几个域,每个域都被大量使用,那么你可以很快地将它们包括在内。 find造成具体问题的人的例子并不难。
结果似乎是,当人们决定同时使用SPF 和几家截然不同的公司来处理他们的电子邮件时,通常会出现问题。 我从你的问题推断你适合那个类别。 SPF似乎不是为那些select这样做的人而devise的 。 如果你坚持这样做,你可能需要在你的DNS服务器上做一些cron工作,不断地评估你希望包含的所有SPFlogging,并将它们expression为一系列ip4:
和ip6:
机制(在其数量没有限制),并重新发布结果作为您的SPFlogging。
不要忘记完成-all
事情,否则整个演习都毫无意义。