Subject: [spfbis] Enhanced discussion of DNS limits/resource considerations

From: Scott Kitterman <[email-masked]>
Date: Mon, 16 Jul 2012 12:15:07 -0400

Alessandro Vesely sent me some proposed changes in section 9 to make some DNS 
limits and costs more clear.  I've attached an rfcdiff of the changes I think 
should be incorporated.  Feedback please.

Scott K

---

From: Stuart Gathman <[email-masked]>
Date: Mon, 23 Jul 2012 23:20:22 -0400

Long ago, Nostradamus foresaw that on 07/16/2012 12:15 PM, Scott
> should be incorporated.  Feedback please.
The cost listed for PTR is misleading.  Only the *first* ptr has that
cost (and only if the MTA has not already looked it up).  Subsequent ptr
mechanisms are free DNS-wise - regardless of argument - because the PTR
records and what they point to are cached.  MX, on the other hand,
potentially costs on every use (with unique argument).

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 24 Jul 2012 00:01:34 -0400

On Monday, July 23, 2012 11:20:22 PM Stuart Gathman wrote:
> > Alessandro Vesely sent me some proposed changes in section 9 to make some
> > DNS limits and costs more clear.  I've attached an rfcdiff of the changes
> > I think should be incorporated.  Feedback please.
> 

The bigger issue to me is reliability.  I don't think PTR should be removed 
because people do use it, but I've yet to find a unique case for it where other 
ways of constructing an SPF record wouldn't work as well or better.  RFC 4408 
tries to warn people away from PTR for, I think, good reason.  I think marking 
it deprecated, to be removed in the future is a good next step.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 24 Jul 2012 03:01:26 -0400

> it deprecated, to be removed in the future is a good next step.

Why is SPF taking the lead when DNS itself doesn't advocate 
deprecation? I think this move is premature, jumping the gun, imposing 
unnecessary change on operators, time/energy/cost to manage DNS more 
regularly when they don't have to today, lacks consideration for 
improved operations and DNS setups, lacks considerations for the 
automated caching of PTR already performed by OSes, etc, etc.

Overall, it is a subjective consideration with little basis to thrust 
on existing operations where once again, many will find (the change 
they need to make and one more complex) unnecessary and remove what 
will be considered by many very useful despite what one may believe is 
not required or they can do a better job at configuration a network 
for SPF.

As stated before if PTR is deemed a problem for SPF, there are 
certainly sound argument to be equally applied to other features, like 
EXIST, like REDIRECT, like INCLUDE which all can use some consultation 
for a better preparedness for less overhead on DNS.

IMTO, this is a DNS management issue, a BCP. Not a SPF problem thus 
does not warrant the drastic change that is being advocated, and in 
addition, offered with no smooth upgrade or backward compatibility 
path. If one supports SPFBIS purely, it will instantly lack coverage 
for a relatively significant amount of the SPF market place. This 
removes the payoff value for SPF gained with the growth of SPF over 
the 8-9 years and will be a dip in the support for a number of unknown 
years before you can gain the wide SPF support.  You will be assuming 
this DIP in growth which will correspond to increase error rates will 
be short, but we have no clue and I don't think it needs to be impose 
on SPF supporters and new developers who will suffer as well with lack 
of coverage.

Please reconsider this move. I think it is better to have a BCP like 
section about "Optimizing SPF policies for DNS" than to begin 
suggesting deprecating features.  IMO, it will serve the same purpose 
and quite frankly, more friendly, without complaints and well without 
pissing people off. :)

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 24 Jul 2012 16:27:01 +0200

On Tue 24/Jul/2012 06:01:34 +0200 Scott Kitterman wrote:
>> Long ago, Nostradamus foresaw that on 07/16/2012 12:15 PM, Scott Kitterman would write:
>>> Alessandro Vesely sent me some proposed changes in section 9 to
>>> make some DNS limits and costs more clear.  I've attached an
>>> rfcdiff of the changes I think should be incorporated.
>>> Feedback please.
>> 
>> The cost listed for PTR is misleading.  Only the *first* ptr has
>> that cost (and only if the MTA has not already looked it up).
>> Subsequent ptr mechanisms are free DNS-wise - regardless of
>> argument - because the PTR records and what they point to are
>> cached.  MX, on the other hand, potentially costs on every use
>> (with unique argument).

That seems to be correct.  Perhaps ptr should have an additional note,
e.g. like so:

    * N is the number of RRs found during a term evaluation
    $ for ptr the query cost is paid on the first evaluation only

Would that sound like encouraging ptr over mx?

> The bigger issue to me is reliability.  I don't think PTR should be
> removed because people do use it, but I've yet to find a unique
> case for it where other ways of constructing an SPF record wouldn't
> work as well or better.  RFC 4408 tries to warn people away from
> PTR for, I think, good reason.  I think marking it deprecated, to
> be removed in the future is a good next step.

Hundreds of domains (0.3%) use multiple ptr's.  It looks like people
who understand the proper use of ptr can easily reiterate it (see
graph).  At the top, monarchinc.com use it 12 times.  Making a better
SPF record at the same cost is not trivial in this case.

The other mechanisms are also repeated many times.  The extremes of
each kind are disconcertingly error prone.  I attach some (hoping not
to trespass size limits...)