Re: Problems using dnswl for SPF

[Matthias Leisi <matthias@xxxxxxxxx>]

> Am 17.01.2016 um 11:18 schrieb Alessandro Vesely <vesely@xxxxxxx>:
> 
> SPF specs include an appendix which details how to avoid to break forwarding:
> https://tools.ietf.org/html/rfc7208#appendix-D
> 
> I'm trying D.1:
> 
>   v=spf1 +ip4:my.ip.add.ress ?exists:%{ir}.list.dnswl.org -all

I must admit that until I read your email I was not aware of that appendix. 

> *Problem 1*
> -----------
> 
> I heard from Google that they get errors evaluating "exists".  Instead of:
> 
> Host 102.1.64.64.list.dnswl.org not found: 3(NXDOMAIN)
>> Host 102.1.64.64.list.dnswl.org not found: 5(REFUSED)
>> Host 102.1.64.64.list.dnswl.org not found: 2(SERVFAIL)

We have three ways of managing access for those doing > 100k queries / 24 hours (which also affects Google’s public DNS):

„parentblock“: we block them on the DNS parent zone (ie, „dnswl.org“). IPs within this group do not receive nameserver information for the „list.dnswl.org“ zone - the list simply does not exist. The advantage of this approach is that we do not get „retry on error“ requests we get with the next one. If one would query it anyway, we would return 127.0.0.255

„refuse“: we actively return REFUSED. This apparently causes some DNS resolvers to retry three times, thus resulting in triple the amount of queries instead of reducing them. That was our original method, but is not used any more due to the increase in query load.

„empty“: Just return an empty result. As this is very hard to find out for affected users (it is basically indistinguishable from a not-listed result), we do not use this any more.


> Note that I issue a tiny number of messages, and my setup is not so common.
> So, I don't think Google issues too many queries due to SPF evaluation.  Even

You may issue a tiny number of messages, but Google’s public DNS do a lot of lookups. Most DNSxLs with a „free for most“ model block Google and other large DNS providers in some shape or form. For machines that process email, using 8.8.8.8 & friends is not a good idea.


> Any idea where do those errors originate?

I would expect Google to return a consistent error :) 


> *Problem 2*
> -----------
> 
> Another problem is how can subscribers manage that situation.  When I need to
> test my own SPF record, I end up querying list.dnswl.org, although I have a
> local copy of it.  That's because the local copy has a different DNS name,
> which is only valid in internal view.  Can this be fixed?
> 
> Setting up a local override of list.dnswl.org looks cumbersome.  It seems to be
> simpler to instruct an SPF evaluator to map list.dnswl.org to a local copy, if
> available, for the purpose of evaluating SPF records.  Any other suggestion,
> anyone?

That’s an interesting situation. As a sender, you may specify in the SPF record that you delegate trust to specify forwarders to list.dnswl.org. As a recipient, you are instructed by the SPF record to check list.dnswl.org. 

If you as a sender have a local override, nobody really cares since recipients need to lookup the „official“ zone anyway. As a recipient, if you are blocked from querying list.dnswl.org, you can not fully evaluate the SPF record. 

But not all hope is lost :) 

Not all people / organisations are able or willing to set up a local rsync’ed DNS mirror, and we would like to offer them a way to query the data also in cases when they do > 100k queries/24 hours. The solution to this issue is the same as the solution to the „SPF when blocked“ issue: allow subscribers to query the „normal“ list — all they need to specify is the IP of the nameserver where they issue queries from. 

(I’m not 100% sure yet on whether this can be implemented in exactly that way, and it will be a couple of weeks until this is finished.)

— Matthias, for the dnswl.org project