-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Radu
Hociung
Sent: Monday, March 21, 2005 11:13 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] DNS Load Summary
I would like to wrap up the discussion on DNS loads, because I'm getting
as tired of it as you are. I don't think we will ever come to a
unanimous consensus.
I agree.
I've asked for the "Council"'s input, since they have pretty much
invented SPF, and they will be defending it in front of IETF when they
go to ask for standardization.
I cannot believe that in one month they did not choose to show
any opinion.
Well apparently they've been reading along, because it's now on the agenda
for discussion at their next meeting.
As it stands, some of you do not agree with my proposal to limit the
number of DNS queries to 10 lookups. I think some do agree. Some even
mentioned it would be nice if it could be made smaller than 10 even.
I don't recall anyone actually agreeing with your proposal on the list. I
did see some support for maintaining the existing limits, but most who spoke
up seemed in favor of a unified limit rather than 10 + 10 + 10.
As far as I can tell, here are the facts that were established. Please
correct me if I'm wrong, but let's not make another 1000-message long
thread of this:
- no disagreement that a clear limit must be specified.
Yes.
- no disagreement that the limit should be a simple number (on
number of DNS queries), instead of a multi-variable forumula.
Although I think that one subtle aspect of this is that the spec defines
what the receiver must do, not how records must be formed, so while a record
should conform to the processing limits, I think that since the spec is
written from the receiver perspective, it's ended up the way it did. To be
clear, the limits should be expressed in a way that makes sense both for
senders and receivers.
- no disagreement that all clients should use the same limit.
I would say that senders should be guaranteed that all clients will process
at least X mechanisms. If someone wants to do more work than that, I don't
think the spec should prohibit that.
- no disagreement that the limit should be lower than the current 111
Does the curent 10 + 10 + 10 still add up to 111? I don't think we spent
much time exploring how many queries are reasonable for MX and PTR.
- general consensus puts the desired limit between 10-20 queries.
With the caveat that we really haven't looked into how many queries it takes
to resolve PTR.
- there was minor resistance to having a global limit (per domain) as
opposed to a per-TXT record limit (recursive/pyramid like).
I think the majority consensus is for 1 global limit.
Since I was the resistance, IIRC, here's an alternative idea:
Overall limit is 15
If you neither include another record nor expect to be included (not an
ISP/ESP), then you may use up to 15, although you should minimize the number
of queries.
If you are an ISP/ESP and expect your record to be included in other
records, then you must not use more than 7 and you should minimize the
number of queries.
If you are including another record, then you should not use more than 7 in
your record and you must not use or include more than 15 total, but you
should minimize the number of queries.
This codifies your idea that ISP/ESPs should have more efficient records.
This also gives domain owners that will use an include a guarantee that they
can use one include and not break the limit, while preserving the option to
go count out the mechanisms if necessary for more complex situations. It
also includes the idea that the record should not be any more expensive than
it needs to be.
- no disagreement that IP4 and IP6 mechanisms should be preferred to
other mechs that involve DNS lookups.
They are preferred where appropriate. They aren't always appropriate.
- suggestions that a "Best Practices"/recommendations document
should be written. Some text was even offered for some
points.
Wouldn't this be a good thing for the new SPF web site!
Anything else?
As I said above, we probably need to understand better how expensive PTR is
before we stop thinking this through.
Thanks,
Radu.
Scott Kitterman