Re: DNS lookup limits

Andy Bakun wrote:
> On Fri, 2005-03-25 at 17:35, Radu Hociung wrote:
> > And since the mask modifier appears to have so much benefit for so
> > little cost and risk:
> >
> > - the mask modifier should be added. Andy is the only one with serious
> >   objections, so once we've cleared up what's best, we'll know if
> >   we should add the m= modifier, or just use the exists: statement.
>
> I have absolutely zero objections to the mask modifier, it is most
> definitely a good addition.  I support its addition.
>
> What I have objections to is the assumption that things will magically
> be better just because it is added to the spec, as if it suddenly fixes
> all the problems that have been proposed that it does fix.
I doubt that anyone is assuming it to be an instant fix for anything. It 
will take time until it is widely used.
> Adding the mask modifier to the records does not do anything for those
> SPF evaluators who treat modifiers as optional (because they can be) --
> the exact same DNS load and amplification issues exist because, while
> the syntax is backward compatible because it's a modifier, the modifier
> needs to be honored in order to see the intended benefit.  So rather
> than it being one party's problem to resolve (the publisher, by making a
> less complex record that causes less load), it is now a two party
> problem, the publisher needs to put the mask in the record, and the
> recipient needs to update their SPF checker.
>
> If SPF-Doom attacks before there is 100% deployed support for the mask
> modifier, people are still more likely to just disable querying of TXT
> records.  Recipients do the work of upgrading their SPF checker but are
> still vulnerable because publishers are not using the mask modifier. 
> Publishers add the mask, but are still vulnerable to increased DNS load
> because recipients have not all upgraded.  One of your examples, Radu,
> had zombies searching for SPF enabled domains to target indirect attacks
> against.  This same issue applies if zombies were to search for
> expensive SPF records that didn't have masks.  Adding things increases
> the changes that the transition will more painful.
You're correct. If the SPF-doom attacks now, it will hurt a couple of 
DNS servers, and serve as a gentle wake up call. But I think largely it 
will go down as a low-risk, low-damage virus. But that's only because it 
seem that only 5% or so of all SPF records are big. And that's 5% of 
very few published. What's 1 million records when there 300+ Million 
domains registered?
   http://www.isc.org/ops/ds/reports/2005-01/dist-byname.php


It's just a good start.

Well, currently I understand that the rate of adoption has slowed to a 
crawl. I think if we were able to do a PR to say that we have made SPF 
much more reliable and robust, and showed a range of applications, such 
as a reliable libspf, a *reliable* DNS server that implements the draft, 
a reliable sendmail/postfix/etc MTA that has a good SPF integration, we 
may be able to spur adoption again.
I've been sitting on the updated version of libspf2, on a well 
integrated sendmail patch, an spfcompiler and shortly a MyDNS server 
that integrates the compiler.
However, I would never release something that has a lot of potential to 
do harm. My estimates for trouble are pretty grim, and I was hoping 
someone would be able to prove me flat-out wrong, in which case I would 
have released all these goodies without feeling remorse.
But that did not happen, so I now need to request the changes that would 
make the scenario for abuse more pallatable. Since we're making changes, 
the mask and a few others are almost freebies, but they will make a big 
difference (eventually).
Of course, we need to have some discussion on the unreliability of A and 
MX records I pointed out, which is brought about by the load-sharing 
abilities built into modern DNS servers.
There is a chance that we'll discover that using A and MX this way is 
just not reliable and should be discouraged. In that case, a high DNS 
lookup limit would be unnecessary, and we may be able to make it to 4 or 
so. This is the limit required for checkers. For publishing records 
behind a compiling DNS server, the off-line record limit would be much 
higher, as David has pointed out. For non compiling DNS servers, the 
record can be SPF compiled and $INCLUDED.
The best way to pull this off, I think it may be to release a libspf 
implementation with a default limit set at 4, and allowing the sendmail 
postmasters to set it higher (say to 15 or whatever they need now in 
order to not break anything). Allow this for a year or so. Then, as new 
versions of the software is released, gradually obsolete the mechanism 
to allow a higher limit than the Draft. By that time the Draft will 
become a standard with the low limit, so the obsolescence of the 
optional limit will be justified.
In the transition time, spend a lot of effort on education and 
awareness, and perhaps personally contacting postmasters with expensive 
records. I think if the major emailers complied, the rest of the world 
would follow. The short list would include ebay, pobox, and a few others.

> I get the impression that masking is considered some holy grail --
> masking does fix a number of things, but it is still a long road ahead,
> a road filled with providing education to those who might (or have) come
> under attack as to what needs to change and why it's not SPF's fault
> (but that still doesn't keep people from blaming SPF).  Adding anything
> new does not short circuit any of the work that needs to be done.
Not a holly grail at all. Just a planned transition that will take some 
time, but is worthwhile because it provides great savings eventually.
The sooner we start, the sooner we'll see the fruit of our work.


Radu.