Re: Re: DNS lookup limit?

Frank Ellermann wrote:
> Radu Hociung wrote:
> > Let's call the real limit of spf-classic-00 *DoS limit*.
> Be careful with that, IIRC t-online.de really has 8 MXs, and
That's fine.  By publishing "v=spf1 ip4:..." they would save the world 
and themselves lot of resources.
> the per-user-policies of spf.pobox.com allowed all users to
> create their very own PermError with a single DNS mechanism ;-)
> If a sender policy like rr.com or the old pobox.com policy
> hits the DoS limit, it's _invalid_ - like a syntax error.
The pobox.com record needs between 3 and 23 queries plus whatever the 
per-user records require. The full SPF record resolves to a list of 18 
IP addresses, plus whatever the per-user policies allows. Not one of the 
18 IP addresses is outside the pobox.com domain, and they all have the 
same MX priority (10). So the entire pobox.com mail infrastructure is 
under the control of pobox. I think there is no reason in this case to 
publish any MX or A mechanisms. All they need to publish is IP lists.
The rr.com record takes 8.4 seconds to fully resolve on my system, and I 
have DSL. It takes 0.125s the second time, once it is all in the local 
DNS server's cache.
The rr.com record resolves to 45 IP blocks. Not one is outside the 
rr.com domain. Not one of the MX's is a secondary MX which is not under 
the rr.com control. Also here I see no need to publish anything but a 
list of IP blocks.
I understand that A and MX mechanisms are necessary when the domain in 
question relies on services of third parties, who's IP and name space it 
does not administer. So if you use an MX which is not under your zone, I 
see the need to point to it with an A mechanism (not even an MX).
So in neither of the pobox.com and rr.com cases do I see any gain from 
using 23 and 76 queries, other than the convenience of one administrator 
who maintains the zone file for those domains. so that's 76 queries and 
8.4 seconds for no good reason that I can see. If I missed something, 
please point it out.
I asked before and got no answer as to what is a legitimate set of 
circumstances that *actually requires* more than a handful of lookups. I 
don't consider the convenience of the zone file maintainer a real 
requirement.
> If it hits your local limits then that's only your personal
> "receiver policy", maybe treat it like a result "none", or
> report an error "5xx go away, your SPF policy sucks".  But
> don't claim that the policy is incorrect in that case, it's
> not.
That's right. And this is where the unreliability of email starts.

To avoid this, I would like to define a number of DNS mechanisms that 
will always be fully expanded at all recipients that claim to be SPF 
compliant. I think this small number is what 'validating 
implementations' should be based on.
If local limits allow more than this bare minimum, more power to them. 
But it should not be a requirement of all mail servers to implement a 
large limit for the number of queries.
Do you think one limit is enough?

I think we need to define two levels:

minimum requirement = "no one stops validating after less than X"
max recommendation = "probably no-one does more than Y queries"

> Wayne introduced the concept of "validating implementations"
> in his draft.  That's a very good idea, if all conforming
> implementations use the same definition of "valid".  But it
> won't work if you'd report your personal limits as "invalid".
I agree. We need all implementation to define valid identically. Their 
definition of DoS may vary, though.
> > how many lookups should be reasonably needed to *reliably*
> > prove authenticity? I think no more than 10. this is the
> > number that will cause infrastructure adjustments.
> You should check such assumptions against existing policies.
> RR and POBOX had reasons for their policies.
I think both of those domains publish irresponsibly expensive SPF 
records, based on the calculations and conclusions I explained above.
> If RR now removes all redudant mx mechanisms, they also lose
> some flexibilty, and they have to be very careful if they plan
> to add new MXs with IPs not covered by a policy without these
> mx mechanisms.
If they grow they need to change the zone file to reflect the new 
servers, right? They need to plan this carefully anyway, and by that I 
mean, publish necessary DNS information "before" the new servers are 
allowed to spew. "Before" = enough time such that the cached records of 
their zone file has had a chance to expire at all DNS servers on the 
internet. I think this equation is something like expiry+2*TTL, but I'm 
sure there is an RFC that deals exactly with phasing in new servers, and 
 phasing out old ones.
> If POBOX removes per-user-policies they lose a major feature.
> OTOH a showcase with an invalid SPF policy makes no sense. ;-)
The per-user-policies I have no problem with, except that any user of 
pobox now has some control over the DNS load seen at any recipient 
domains. I think that after the first abuse incident, pobox will either 
introduce strict checking of the consequences of published 
per-user-records, or will discontinue the feature altogether.
By the way, one of the features I'm planning for the libspf2 1.0.6 
release is an optimizer. The optimizer would take in an SPF record, and 
print out the minimalist equivalent SPF record, removing redundancies, 
replacing queries with IP addresses when the queries are under the same 
zone file as the top level, etc.
eg: for example.com: "v=spf1 a a:mx2.bigfish.com" would be optimized to:
v=spf1 ip4:192.0.34.166 a:mx2.bigfish.com"
It will also substitute mx's that end in example.com with the IP 
addresses that the mechanisms would resolve to.
The idea of this is that the zone-file maintainer would edit the 'wordy' 
 record, which contains relative references to a minimal SPF record 
that contains IP addresses wherever possible. He would then publish the 
optimized record, and keep the wordy record on file for future maintenance.
With the proper makefile, the zone IP list is updated at the same time 
as the zone file is updated due to mail configuration changes.
Greetings,
Radu.