On Aug 22, 2013, at 4:36 AM, Jelte Jansen
<jelte(_dot_)jansen(_at_)sidn(_dot_)nl> wrote:
On 08/21/2013 08:44 PM, Olafur Gudmundsson wrote:
Most of the recent arguments against SPF type have come down to the
following (as far as I can tell):
a) I can not add SPF RRtype via my provisioning system into my DNS
servers
b) My firewall doesl not let SPF Records through
c) My DNS library does not return SPF records through or does not
understand it, thus the application can not receive it.
d) Looking up SPF is a waste of time as they do not get through, thus
we only look up TXT
So what I have taken from this is that the DNS infrastructure is agnostic to
RRtype=99 but the
edges have problems.
As to the arguments 7 years is not long enough to reach conclusion and force
the changes through the
infrastructure and to the edges. The "need" for SPF has been blunted by the
"DUAL SPF/TXT" strategy and
thus we are basically in the place where the path of lowest-resistence has
taken us.
What I want the IESG to add a note to the document is that says something
like the following:
"The retirement of SPF from specification is not to be taken that new
RRtypes can not be used by applications,
the retirement is consequence of the dual "quick-deploy" strategy. The IETF
will continue to advocate application
specific RRtypes applications/firewalls/libraries SHOULD support that
approach."
So what makes you think the above 4 points will not be a problem for the
next protocol that comes along and needs (apex) RR data? And the one
after that?
There are two reasons, mail is a legacy application with lots of old cruft
around it.
New protocols on the other hand can start with clean slate, and the use of the
protocol is
optional unlike email.
With a new protocol you can tell someone "you can not use Vendor X as it does
not support Y"
and they will put up a system that works, for email there is installed base and
enterprise policies to use
Vendor X then SPF RR can not be used.
While I appreciate the argument 'this works now, and it is used'
(running code, and all that), I am very worried that we'll end up with
what is essentially a free-form blob containing data for several
protocols at the zone apexes instead of a structured DNS.
So if this approach is taken, I suggest the wording be much stronger, in
the hope this chicken/egg problem (with 5 levels of eggs. or chickens)
will be somewhat mitigated at some point. Preferably with some
higher-level strategy to support that goal.
Jelte
I agree
Olafur