Re: [dnsext] Obsoleting SPF RRTYPE

[Andrew Sullivan <[e-mail]>]

Dear colleagues,

First, no hat, but just for context: I am co-chair of the moribund
dnsext and also of spfbis.  Glancing at another hat, I am acutely
aware of recommendations the IAB has historically made about the use
and extension of the DNS, and I mostly agree with those observations.
To emphasise, however, I am speaking here in an individual capacity.

This conversation should probably move to spfbis@ if we're going to
have it out, but I want to make sure that people who haven't been
following that WG have the appropriate context.

On Thu, Apr 25, 2013 at 11:13:29AM +0000, Ted Lemon wrote:

> Then perhaps we should all tromp on this in IETF last call.   I certainly agree with your take on this: the idea that a document would advocate the use of a TXT record because promulgating SPF records is "too hard" is just broken.
> 

I'm not sure whether Ted is offering advice above to a still-active WG
of which he is the shepherd, or participating as an individual, but in
any case I'd like to point out that the documents in question (one of
which is already an RFC) don't advocate new use of TXT because another
type is "too hard".  There's actually an interoperability problem, and
there's a simple fact of deployment.  The IETF has not had notable
success when it pretends to be King Canute, and I think "tromping on
this" would be an example of such behaviour.

First, it is worth noting three things about the co-existing SPF and TXT
records described in RFC 4408.  The first is that a server using SPF
MUST publish at least one of them.  The second is that a client using
SPF MUST query for at least one of them.  The third is that there was
never any specification of interdependency between these records. 

The consequence of those three things is that there's a basic interop
problem in RFC 4408: if a server only publishes SPF records and a
client only looks up TXT records (or conversely), they both implement
the protocol as specified and yet the communication fails.  So, this
is broken.

Now, SPFBIS was chartered to move SPF from experimental to the
standards track, on the not-implausible premises that it's a widely
deployed technology and, indeed, 4408 was never really an experiment
anyway.  To fix the interop problem above, we have three options:

    1.  Specify that clients query first SPF, and then query TXT if
    SPF returned NODATA.

    2.  Specify that clients first query TXT, and then SPF if TXT
    returned either NODATA or a TXT record that wasn't an SPF record.

    3.  Deprecate one of the types.

We rejected (1) (in consultation with DNSOP) on the grounds that the
evidence showed overwhelmingly that deployed systems used TXT in
preference to SPF.  A number of systems (including, full disclosure,
one of the services that my employer, Dyn, offers) to this day only
support SPF using TXT records.  So, (1) would result in an increase of
query traffic with little, if any, benefit.

We rejected (2) on the grounds that, since nearly every system we
looked at (and all the systems that didn't appear to be operated by
DNS nerds) published a TXT record for SPF (and maybe also published an
SPF record), the SPF type lookup would just never happen.  Ditching
the additional lookup logic leads to a simpler specification and
simpler implementations, at no apparent cost.  Moreover, if everyone
migrated to type SPF, (2) would be bad in the same way (1) is, only
worse because of the additional complexity caused by having to examine
every TXT record at an owner name prior to falling through.

This led us to (3).  Of course, in (3), we could either deprecate the
SPF type or the use of TXT for this purpose.  But the deployed base
has clearly spoken: TXT is the overwhelming preference, and almost
everyone who publishes an SPF record also publishes a TXT SPF record.
Deprecating the TXT use would mean that the actual deployed software
would never stop using 4408 as its specification, because of the
massive backward compatibility problem that would arise.

I am very, very unhappy about this fact, but it is a fact of the
world, and I think the IETF just makes itself look ridiculous if it
attempts to make the rest of the world work the way we would like.
There is no question that it is architecturally lousy that we're using
TXT records for this.  The underscore-label convention, as much as it
gives me hives, offers a way for future innovations to avoid trouncing
all over the TXT record at an owner name, so I don't think SPF
functions as any kind of precedent.  And I, as much as anyone, am
extremely keen to promote the idea that new RRTYPEs are often a good
idea.  But we are just not in a position to try to tell the Internet
not to use TXT in this particular case, and I think we're dreaming in
Technicolor if we suppose that we could.

Best,

A

-- 
Andrew Sullivan
[e-mail]