Murray, On Apr 30, 2013, at 11:29 AM, Murray S. Kucherawy <superuser@xxxxxxxxx> 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