Re: SPF-compiling DNS Server

David MacQuigg wrote:
> At 11:32 AM 3/24/2005 -0600, you wrote:
>
> > On Thu, 2005-03-24 at 11:03, David MacQuigg wrote:
> > > In addition to patches for the various name servers, it would be 
> > nice to
> > > have something that could be deployed rapidly, without even stopping a
> > > running DNS server.
> >
> > I'm not sure what "stopping a running DNS server" means in this
> > context.  DNS hosters who provide web interfaces to DNS zone maintenance
> > already effectively do just that, in as much as the person editing the
> > records doesn't need to do a kill -HUP or anything, they just need to
> > hit a button on a web form.
>
> Patching a DNS server would be more disruptive than necessary.  
> Installing a daemon to automatically update SPF records could be done 
> without any disruption.  The web interface you mention above is a good 
> example.
> > > If we make this nice enough, admins will update their records long 
> > before
> > > SPF-doom arrives.
> >
> > Update them to what?  This putting the cart before the horse.
>
> Update from an inefficient, manually-written SPF record to a compiled 
> record, generated automatically from the original SPF record, or its 
> subsequent updates.  The update is the horse.  The cart is an efficient 
> system for doing SPF queries, one that will never tempt virus writers to 
> try an attack.  If updating were a big burden, then you might say, let's 
> wait until we see an attack, then push everyone to update.  If we make 
> it simple and fun, many admins will update, just because it is easier 
> than what they did before.
I would discurage such a game of wait-and-you'll-see. Instead, a focused 
 and well thought out education campaign would be a better way, I feel.
Council, any thoughts/initiative on this?

> > Any updates have to be compatible with the current spec (or are we
> > thinking that there is some holy-grail of SPF mechanisms that is low DNS
> > load and completely describes the domain that we should add to the
> > spec?)  Any changes to the DNS software to make them SPF aware, which
> > seems much more likely as being backward compatible, is not something
> > that someone who edits their zone files via web interface their DNS
> > service providers provides can do.
> >
> > If there is any change that can happen to reduce the chances of this
> > mythical "SPF-doom" virus from having a significant impact, it is to
> > make a low-load SPF record that is all ipv4.  But I thought we already
> > agreed that that removes the things that make SPF SPF and that's not
> > what we want.  Are we pushing for RMX in that case?  If so, then lets
> > just use RMX and be done with it.
>
> As I understand it, the benefits of all the inefficient SPF mechanisms 
> are for convenience in setting up SPF records.  The only thing needed by 
> the SPF checker is a list of IP addresses (or blocks).  The 
> SPF-compiling daemon provides a versatile syntax for the user, and an 
> efficient syntax for the checker.  None of this requires changing the 
> SPF spec.
> > Where is the middle ground?  If using any mechanisms other than ipv4
> > (and ipv6, of course) then the system has a DNS load/query amplification
> > issue.  How much amplification is acceptable?  I'm reading that none is
> > acceptable.  In some cases, the amplification is directly related to
> > accepted DNS configuration and currently deployed network topologies
> > (mx:aol.com amplifies to greater than mx:leave-it-to-grace.com because
> > there are more queries and records behind aol's mx).  Do none of the
> > other benefits of the SPF syntax and (comparatively) rich mechanisms
> > outweigh this possibility of an SPF-doom attack, an attack that may be
> > on SPF (either technically or socially) but isn't actually SPF's fault?
Acceptable amplification. Great question.

Sendmail currently does at least 3 queries for every incoming 
connection. (PTR against the IP, A against the resulting name, and A 
against the MAIL FROM domain).
The A query against the MAIL FROM domain is only looking for NXDOMAIN or 
a real response (even empty), in order to weed out domains that do not 
exist. This query should be replaced with the first TXT query of the SPF 
check. If it returns NXDOMAIN, sendmail rejects the mail as before. If 
not NXDOMAIN, then we have an SPF result (none or something else).
So far, we have added no more DNS load than we currently have. The 
incremental cost of SPF starts when we expand the first DNS mechanism. 
If the only DNS mechanism is a PTR, that is nearly free, because the 
result to that is already in the cache since the query done before EHLO.
The amplification caused by SPF only starts at the first non-PTR 
mechanism expanded in a policy.
> Maybe I'm misunderstanding something, but can we not keep all the mx 
> lookups, etc. in the user syntax, and still have the compiled record be 
> nothing but a list of IPs?
That would be the best idea.

Radu.