spf-discuss
[Top] [All Lists]

Re: short circuiting evaluation

2005-03-24 20:17:43
On Thu, 2005-03-24 at 15:14, Radu Hociung wrote:
Andy Bakun wrote:
This is a very interesting idea, Radu.  Couldn't you currently short
circuit your entire eBay compiled record with:

        domain.com.        TXT "v=spf1 ~exists:%{ir1}._spf.%{d} "
                               " ...restofrecord... ~all"
        X._spf.domain.com. A   127.0.0.1 


(with 243 of these records, for all values of X in 0..255 except for the
13 you've listed that eBay uses) ?

But ebay's server is doing the compilation, and they might not have an 
RBL like map (which is what the exist mech implies).

In what way does the exists mechanism imply that there is a RBL behind
it?


They'd have to publish:
1._spf.ebay.com A 127.0.0.?
...
254._spf.ebay.com A 127.0.0.?

Yes, that is exactly what I said, except for the 13 entries that prefix
the IP blocks they have valid senders in.  If the records to publish are
generated by the compiler, this isn't that big a deal.



Also, this exists mech would likely generate an DNS packet across the 
net, because the host with %{ir1} is probably not in the cache.

After forgers from all corners of the world send me "ebay" email, my 
cache would have 243 junk entries.

So would it exist in the cache or wouldn't it?

Those wouldn't be "junk entries" during a zombie attack.  They would
serve the purpose of not having to evaluate the entire SPF record, no
matter how complex it is (all ip4 or some mix of other mechanisms).

In addition, as I said, _if_ one was to put a stunt DNS server behind
that _spf subdomain, the stunt DNS server could serve DIFFERENT cache
expiration times based on the load it is seeing.  During low load times,
it could serve zero, so it doesn't pollute the receiver's cache.  During
zombie attacks, it could increase it so the SPF checkers don't need to
perform DNS-load-increasing queries all the time.



Also, I was suggesting that the compiler would generate far more narrow 
masks. I listed a few 8-bit ones that I noticed manually. I spent no 
effort to make them better.

So if there is a forger at 65.0.0.1 and ebay uses 65.12.12.12, its 
exists mechanism cannot return a positive for 65._spf.ebay.com, or it 
would shoot down its own outgoing server. In order to not do this, it 
would have to publish %{ir2}._spf.{d}, but this is not very flexible, as 
it cannot generate an arbitrarily tight blackout pattern like the mask can.

The exact optimization I was suggesting with this is that exactly what
the subject line says: short circuit the rest of the record.  A single
query can rule out the evaluation of the rest of the record, no matter
what the rest of the record is, as such, the number of queries required
for a significant portion of the internet is 1.  Putting the negation of
your range in zone files is necessary to implement this because there
is, unfortunately, no way to negate a check.  That is:

        -a:64/8
        
means

        if the IP starts with 64, then it is not authorized
        
not

        if the IP doesn't start with 64, then it is not authorized
        
But you can do the latter with:

        -exists:%{ir1}.%{d}
        
And add RRs for all the entries that are not allowed.

This means you can put more expensive entries after the exists, and use
a shorter, non-chained record, which results in fewer queries also. 
Your ebay example:

ebay.com             TXT "v=spf1 ip4:66.135.195.180 ip4:66.135.195.181 
ip4:66.135.209.192/27 ip4:66.135.197.0/27 redirect=_s0.%{o}"
_s0.ebay.com         TXT "v=spf1 ip4:64.4.240.64/27 ip4:64.4.244.64/27 
ip4:66.135.215.224/27 ip4:216.33.244.96/27 redirect=_s1.%{o}"
_s1.ebay.com         TXT "v=spf1 ip4:216.33.244.84 ip4:67.72.99.26 
ip4:206.165.246.83 ip4:206.165.246.84 ip4:206.165.246.85
redirect=_s2.%{o}"
_s2.ebay.com         TXT "v=spf1 ip4:206.165.246.86 ip4:64.127.115.252 
ip4:194.64.234.129/27 ip4:65.110.161.77 ip4:12.155.144.75
redirect=_s3.%{o}"
_s3.ebay.com         TXT "v=spf1 ip4:62.22.61.131 ip4:63.104.149.126 
ip4:64.68.79.253 ip4:64.94.204.222 ip4:66.135.215.134 redirect=_s4.%{o}"
_s4.ebay.com         TXT "v=spf1 ip4:67.72.12.29 ip4:80.93.9.10 
ip4:195.234.136.12 ip4:203.49.69.114 ip4:209.63.28.11 redirect=_s5.%{o}"
_s5.ebay.com         TXT "v=spf1 ip4:210.80.80.136 ip4:212.110.10.2 
ip4:212.147.136.123 ip4:213.219.8.227 ip4:216.113.168.128
redirect=_s6.%{o}"
_s6.ebay.com         TXT "v=spf1 ip4:216.113.175.128 ip4:216.177.178.3 
ip4:217.149.33.234 ip4:220.248.6.124 ip4:67.72.12.30 redirect=_s7.%{o}"
_s7.ebay.com         TXT "v=spf1 ip4:216.113.188.112 ip4:80.66.137.58 
ip4:212.208.64.34 ip4:216.113.188.96 ~all"

Requires a variable number of queries in general up to nine, and nine
exactly in order to find out if 216.113.188.96 is allowed, since it is
last in the list, and always nine if the IP is not authorized.  Rather,
my alternative 244 (1 SPF TXT + 243 A) records reduce the number of
queries to TWO [physical] in the worst case independent of caching:

"v=spf1 -exists:%{ir1}._spf.%{d} +mx -all"

1 for the exists and 1 for the MX (if the entire MX list fits in the
additional portion of the MX response).  In any case, this gains back
some of the usefulness of the other mechanisms without having to
recompile (or test for needing to recompile) continually and without
forcing their complex evaluation in all instances.  The cache expire
time for the records used in exists should definitely be kept low.

This is simply trading space (number of records) for time (number of
queries).  It is _another_ way to compile records, which has its
benefits and trade offs too.
-- 
Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com>


<Prev in Thread] Current Thread [Next in Thread>