Re: SPF isn't going to change, was Deprecating SPF

>> 	so on one hand, you have the second query (load & latency)
>> 	((exactly like a CA lookup))  v.  the RR demux that has to occur
>> 	for type 16.
>> 
>> 	sounds like the tradeoff between code complexity and network latency...
>
>Except that as a matter of fact, one of them is very likely to be
>needless cost.  That is, you're going to need to cope with the TXT
>record _anyway_, because that's what's deployed everywhere.  So you
>have to pay cost of code complexity for demuxing no matter what.

Actually, it's worse than that.  The SPF rules for handling type 16
and type 99 records are identical, so you have to make the same checks
that there's exactly one record with the SPF prefix tag for type 99
records as you do for type 16.  You pay the demux penalty, such as it
is, for both.

In practice, there are likely to be fewer type 99 records than type
16, but the CPU time for the checks is trivial compared to everything
else a mail server does. We've seen at least one live example of
invalid type 99 records that would fail the checks here in the past
week, so the checks are not wasted effort.

R's,
John

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext