Re: Re: It's published!

Frank,

Reading your attached, I began to wonder if it might make sense to have 
something like the DNS root servers to support SPF processing.  By this, I 
mean a server set that answers to a query simply offering basic 
confirmation of the ability to process and not any actual SPF processing 
syntax which must be managed at the domain's DNS servers.  I suggest this 
because one does not know what they will receive back from the owning DNS 
until a request for the TXT record is actually placed.  If the record is 
malformed and causes problems for processing either inadvertently or 
maliciously, having a place to check for some basics might be a good idea 
and could short circuit efforts to damage SPF processing.
When querying a root SPF "authority", client software to the "authority" 
might ask something like "spfx domain.tld" and get responses like 
PermError, NONE, SPFx, etc.  Where SPFx might mean the highest version of 
SPF record one should expect when querying for a TXT record at the DNS for 
domain.tld as well as that the record itself is syntactically correct for 
that version.  I see this as a way to reduce the computational challenges 
for adopters who might want to know if it is even worth processing a given 
SPF record for a given domain.
Obviously, whatever the root SPF "authority" servers say may or may not be 
believed by the accessing server (at the discretion of those who implement 
such a proposed check in their SPF server implementations), so it does not 
change the current ability to go fetch an SPF TXT record directly from the 
domain's DNS, but it could reduce SPF processing problems.
Best,

Alan Maitland
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/


At 04:44 AM 10/17/2004, you wrote:
> Mark Lentczner wrote:
>
> > For now, I suggest that this be the normative reference
>
> ACK.  But "we" (= you ;-) can still try to add some of Wayne's
> points.  His idea about limiting DNS queries makes sense for me,
> but maybe his proposed solution was a bit too complex.
>
> In essence it's possible to get rid of the SPF DDoS scenario
> in the "security considerations" completely:
>
> - remove the overall (optional) evaluation timeout (7.2)
> - remove the DDoS disclaimer in "security consideration" (10)
> - remove the limit "ten check_host() evaluations" (7.2)
>
> Replace all this stuff by a new limit of evaluated directives.
> The exact number to be determined, let's say 10 for the moment,
> each a / mx / ptr / include or redirect= counted as "one step",
> ignoring ip4 / ip6 / all.
>
> Define it as hard limit:  "Each sender policy MUST reach a
> final 'all' directive after at most 10 evaluated directives
> resulting in any DNS query.  Otherwise the result is PermError"
>
> With this hard limit tools like the wizard could automatically
> detect invalid sender policies.  Unlike vague global timeouts
> this evaluation limit works reliably.  All timeout problems in
> SPF are then caused by DNS, and independent of the check_host()
> implementation.
>
> A single simple limit is IMHO better than Wayne's idea of many
> individual limits, although mx / ptr can be much more expensive
> than any a / include / redirect=.
>
> 10 directives in Wayne's "13 MX" example still results in 130
> DNS queries.  But 10 check_host() evaluations as in the current
> draft could be almost anything, e.g. 10 * 20 * 13 queries, and
> that's too much.  Aborting 2600 DNS queries after 20 seconds
> doesn't help for the victim, if these queries are triggered by
> say 200,000 DDoS spam mails.
>                              Bye, Frank