It's seems that num_dns_mech is not getting passed around down and then up. Which leads to limit data being effectively reset on each nested level.
Did a manual check to be sure using a known offender that has 15(!) mechanisms in total (this can be verified independently):
$ spfquery -ip=1.1.1.1 -sender=ae-news.a5@deals.aliexpress.com -max-lookup=4
fail
Please see http://www.openspf.org/Why?id=ae-news.a5%40deals.aliexpress.com&ip=1.1.1.1&receiver=spfquery : Reason: mechanism
spfquery: domain of deals.aliexpress.com does not designate 1.1.1.1 as permitted sender
Received-SPF: fail (spfquery: domain of deals.aliexpress.com does not designate 1.1.1.1 as permitted sender) client-ip=1.1.1.1; envelope-from=ae-news.a5@deals.aliexpress.com;
See how it works exactly with the number (4) that matches the top-level count of mechanisms that cause DNS lookups:
deals.aliexpress.com. 600 IN TXT "v=spf1 include:spf1.ocm.aliyun.com include:spf1.service.alibaba.com include:spf2.service.alibaba.com include:spf2.ocm.aliyun.com -all"
And only when I use 3 as the limit it starts generating a limit failure:
spfquery -ip=1.1.1.1 -sender=ae-news.a5@deals.aliexpress.com -max-lookup=3
StartError
Context: Failed to query MAIL-FROM
ErrorCode: (18) Mechanisms used too many DNS lookups
EndError
permerror
spfquery: error in processing during lookup of domain of deals.aliexpress.com: Mechanisms used too many DNS lookups
Received-SPF: permerror (spfquery: error in processing during lookup of domain of deals.aliexpress.com: Mechanisms used too many DNS lookups) client-ip=1.1.1.1; envelope-from=ae-news.a5@deals.aliexpress.com;
This is pretty serious issue that is directly addressed by the rfc7208. Absence of proper limiting can be abused to make DNS amplification attacks by simply building a huge tree with branches managed by the attacker and leaves, having 10 records each, pointing towards victims.
Am I missing something here? Maybe there is some other limit, that even though the RFC's requirements are disregarded, won't allow a real harm to be made?
It seems that the library is incapable of correctly tracking the number of issued DNS queries when handling recursive mechanisms such as
include:.The only place I've found the related error is at https://github.com/shevek/libspf2/blob/master/src/libspf2/spf_interpret.c#L758 and later on in the same function, when handling
PTRentries.It's seems that
num_dns_mechis not getting passed around down and then up. Which leads to limit data being effectively reset on each nested level.Did a manual check to be sure using a known offender that has 15(!) mechanisms in total (this can be verified independently):
See how it works exactly with the number (4) that matches the top-level count of mechanisms that cause DNS lookups:
And only when I use 3 as the limit it starts generating a limit failure:
This is pretty serious issue that is directly addressed by the rfc7208. Absence of proper limiting can be abused to make DNS amplification attacks by simply building a huge tree with branches managed by the attacker and leaves, having 10 records each, pointing towards victims.
Am I missing something here? Maybe there is some other limit, that even though the RFC's requirements are disregarded, won't allow a real harm to be made?