Re: Problems using dnswl for SPF

[Alessandro Vesely <vesely@xxxxxxx>]

On Mon 18/Jan/2016 06:00:59 +0100 Matthias Leisi wrote:
>> Am 17.01.2016 um 11:18 schrieb Alessandro Vesely <vesely@xxxxxxx>:
>> 
>> *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):

I'm not clear how one of those methods is selected.  Are you still adjusting
those settings?

> „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.

That looks quite nasty.  It also increases NS load.

> If one would query it anyway, we would return 127.0.0.255

You mean if one had cached your NS' IPs?

I'm no DNS expert, but returning 127.0.0.255 --except for special test cases--
looks like the best option to me.  Its meaning is clear, albeit not
standardized yet.  Software which is going to interpret the return value should
check it and log a warning in case.  Software relying on mere existence will
see most of the world whitelisted, which is not as disrupting as blacklisting,
and similar to some 127.0.x.0.  And it is the less resource-demanding reply,
anyway.

> „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.

Right.

>> 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.

Besides SPF's "exist", are there other ways that can induce a server to query a
DNSxL unwittingly?  Anyone who configure their server software to query
specific zones ought to be aware of the subtended volumes.

> For machines that process email, using 8.8.8.8 & friends is not a good idea.

Very strongly agreed.  MTAs deserve dedicated NSes.

>> Any idea where do those errors originate?
> 
> I would expect Google to return a consistent error :) 

How would they distinguish the meaning of the result from any other possible
DNS quirk?  The very fact that REFUSED can cause retries indicates that
querying software has difficulties in interpreting rcodes different from 0 and 3.

Ale