Doug,
Aren't you tired of repeatedly pointing out your half of the argument? I
am of ours. The Monty Python argument clinic sketch comes to mind.
On Tue, Apr 30, 2013 at 10:11 AM, Doug Barton <dougb(_at_)dougbarton(_dot_)us>
wrote:
The discussion about this on the spfbis list all revolved around the fact
that TXT is widespread, SPF/99 is rarely used, so let's just stick with
TXT. In a pre-3597 world there _were_ problems with querying for SPF first,
so the fact that historically querying for SPF/99 first was painful is a
valid data point. However the problems encountered in the early days of SPF
deployment with servers not handing unknown types gracefully haven't been
relevant for many years now. Yet, the SPF community has continued to push
TXT only, in spite of the advice of 4408. Almost like a self-fulfilling
prophecy ...
As has been repeatedly pointed out, the "haven't been relevant for many
years now" conclusion you've reached is contradicted by both anecdotal and
empirical data.
I assure you that I hear all of the points you are making. I also assure
you that none of them resolve any of the points being made on the other
side. There's no dialog happening here.
The reasons brought forward by participants in the spfbis group to not
make this change all revolve around the fact that it would involve
additional work. Personally I don't find those arguments compelling.
Sure, because you don't have to do the work, nor are you confronted with
the weight of the long tail in this case. I submit that it is presumptuous
to assert that the properties of one community's long tail problems are the
same as they are in others.
First, some of the arguments about the extra work are just plain silly
(ala, "cut and paste of the same data for 2 RRtypes is too difficult").
I don't think anyone said that's difficult. I would also point out that
it's not difficult, given a jumble of TXT RRs in a reply, to find any that
start with a particular identifying substring which would mean "this is an
SPF record", so let's nip that one in the bud right now.
These are all distractions from the real points being made.
Second, there are not that many implementations that query SPF, and the
change is not difficult.
Nobody said that's a problem either.
Third, most of the "work" to be done is to wait for time to pass and for
people to upgrade to the new versions of software. This is a bog-simple
"long tail" problem that we deal with in the DNS world all the time.
...during which time the service arguably operates in a degraded state.
The assertion that "You should just fix your DNS infrastructure!" ignores
the fact that the interfering piece of the infrastructure may not be under
the control of the operator who can't complete an SPF operation, or, worse,
that the owner of the problem lacks the resources or interest to get it
fixed for a long while, if at all.
Do we just have SPF operators call you for emotional support during this
protracted transition time?
Not only is this a case where doing the right thing is good for SPF, the
SPF example of "let's just go with TXT because using a new RRtype is hard"
has spread like wildfire, especially in the mail authentication world
(DKIM, DMARC, etc.). The slippery slope has been well-greased at this
point, and it would be nice to move things back in the right direction (see
5507 for example).
This is also a separate argument given the underscore prefix debate.
To be fair, there was one other objection raised, which is that DNS
provisioning systems haven't caught up with the need for new RRtypes. So
some can't go to their registrar's/web hoster's/etc. web interface and
enter a proper SPF record. That's a problem, sure. But it's a problem that
has to be solved, assuming we're actually going to take the advice in 5507
seriously. Personally I'm not willing to allow all progress forward in DNS
to be stymied by those unwilling to make an investment in their own
infrastructure.
What are you prepared to do to help address the broken infrastructure?
It's all well and good to lob directives over the wall, but I'd like to
hear some advice about how to compel inattentive infrastructure operators
to make these changes, especially when those operators aren't necessarily
the ones affected.
-MSK