Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE

[Nicholas Weaver <[e-mail]>]

On Apr 26, 2013, at 8:13 AM, Ted Lemon <[e-mail]> wrote:
>> On the other side, here are the arguments that I understand to have been made:
>> 
>> 1. TXT records are not specific to SPF, thus we can't assume that any given TXT record is an SPF record.
>> Rejoinder: doesn't seem to be an issue in practice—no other TXT records are needed on the names to which SPF TXT records are typically attached.
>> 
>> Moreover, parsing TXT records is not hard, nor is answering the question "Does this one start with the string 'v=spf1'?".
> 
> Sure, and a base-64 encoded string will never have an equals sign in that position, so we don't have to worry too much about a random collision.

Yeah, we don't.  

IF the string is random, thats a 1 in 2^36 chance.  Yawn.

And if the string is "malicious" and deliberately constructed to be a bad record starting with v=spf1, it only screws up the domain owner's SPF record, so who gives a flying fig?  The domain owner can correct it, be done with it, and move on.

>> 2. Because TXT records aren't specific to SPF, a query for TXT records may return an unexpectedly large result set, requiring fallback to TCP.
>> Rejoinder: doesn't seem to be an issue in practice.
>> 
>> That's not correct; there are still packet filters out there configured by default to disallow TCP over port 53.  We discovered this during the RFC6686 surveys.
> 
> These two points taken together seem like a pretty strong argument in favor of _not_ deprecating the SPF record; in this case, only the SPF record would have made it back to the MTA.

If you want DNSSEC, you got to fix THAT problem anyway.