wayne wrote:
In
<5(_dot_)2(_dot_)1(_dot_)1(_dot_)0(_dot_)20050504164603(_dot_)043275e0(_at_)pop(_dot_)mail(_dot_)yahoo(_dot_)com>
David MacQuigg <dmquigg-spf(_at_)yahoo(_dot_)com> writes:
At 05:42 PM 5/4/2005 -0400, Radu Hociung wrote:
Here are my partially formed opinions:
1) DNS has a few flaws in its design. [snip]
Yeah, but for something that was deployed in 1983(?), back when a lot
of people didn't even have a PC, it has scaled amazingly well with
very few changes.
Indeed ... a great example of good engineering, with little left to chance.
The little that was left to chance was security, and it's taken 10 years
of farting around, and DNSSEC is still a dream. If that detail were
considered from the beginning, it would have saved at least 10 years,
and who knows how many millions of dollars in related costs (diverted
websites, security complaints, down time to patch the cache spoofing
bug, etc).
Let's learn from history, shall we?
Attention to detail is all I preach and practice.
2) SPF made a mistake in abandoning the _trick. Now we have to deal
with overcrowded TXT records, and a migration headache from TXT to SPF.
Before we switched to putting the SPF record at the email domain
level, there were two surveys done. One looked at how often there
were already TXT records there, and the other, as you mention above,
about how many DNS hosting services would allow an underscore. The
TXT record usage showed that we would probably be safe and that there
really wasn't much "overcrowding" of TXT records. Later, during the
MARID WG, I did much more extensive surveys on TXT record usage and
the size of SPF records and showed that there REALLY isn't an
"overcrowding" problem with TXT records.
In hind sight, I think we made the right choice.
At the time there was no overcrowding, but now everyone wants to put
their stuff in the TXT record at the top level.
Had you chosen an extension, the competing ideas would also be picking
their own extensions.
Picking the top-level domain as a host for the SPF record was setting an
example for future ideas. More attention should have been paid, not to
the then-current crowding situation of the top-level TXT record, but to
the unfolding of subsequent events.
If we're slightly worried about overcrowding now, when it's not yet a
prominent problem, how will it be in 5 or 10 years ? Is it likely to
actually become a real problem? I think so.
Anyway, there's not much point debating this, I don't think, because
like you mentioned, an SPF-replacement standard is probably needed to
clean up the deficiencies of the "Classic" spec.
Regards,
Radu.