Murray,
On Apr 30, 2013, at 11:29 AM, Murray S. Kucherawy
<superuser(_at_)gmail(_dot_)com> wrote:
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.
SPF using TXT and hence, SPFBIS forces the uniquification of the DNS response
into the application instead of in the DNS library. Given the ordering of
individual TXT RRs within an RRset is not guaranteed, I suspect the chances
that every application is going to do that parsing correctly is relatively low
(btw, the example in 3.3 in spfbis-14 is a bit misleading: assuming "second
string" is in a separate TXT RR (which is implied), the concatenation might be
"second stringv=spf1 ..... first"). The more interesting bit is if/when
another protocol uses TXT at the same ownername.
What are you prepared to do to help address the broken infrastructure?
Argue against deprecating the SPF RR :).
The RR has been allocated and it is supported in most DNS servers and resolver
libraries in one form or another. Provisioning systems take much longer, but
that isn't surprising and shouldn't be an argument to deprecate (if it is, we
might as well close the RRtype registry for new entries).
In the past, the IETF used to make decisions based on long-term
technical/architectural correctness, even in the face of pragmatic
complications (e.g., the choice to mandate strong crypto despite real world
challenges some companies faced in exporting that crypto in products). In this
particular case, there seems to be an argument to explicitly disallow the
long-term technically/architecturally correct approach because some folks
choose not to add an RR to their zone files or support that RR in their
provisioning systems. As I said in DNSEXT, this seems like the wrong approach
to me.
Regards,
-drc