On 5/18/2004 9:26 AM, Eric A. Hall sent forth electrons to convey:
On 5/18/2004 10:45 AM, wayne wrote:
What problems, if any, is SPF causing with the DNS
infrastructure/operations?
Wrong tense. The purpose is to avoid problems before they happen as a
result of popular deployment, especially the easy ones. The inevitable
problems from using TXT as a carriage mechanism are:
1) collision with every other expiremental RR encoded into TXT,
such as (eg) base64-encoded documents attached to nodes in the
namespace, or any other research effort that broke out of the
petri dish, and which have nothing to do with spam. there is
no way for you to say that you only want the SPF TXT and not
the other TXT RRs at the same domain naame -- you get them all.
Any specifics on one that matters?
I'd bet that other users of TXT would, like SPF does, typically mark
their records, and as pointed out, the typical SPF record is
30-something bytes, and any particular record does not need to be any
longer than that.
2) even if you move the RR to some other point in the tree, it's
a bad idea to be extra liberal with the encoding. large DNS
messages and answer sets have to leave the UDP-based
What large DNS messages? The evidence presented shows that SPF records
are weighing in at way under 512 B.
infrastructure, requiring point-to-point queries, which are
are not cached by intermediary systems. large, unencoded
RRs and sets thus introduce more work for everybody and
actually decrease the value of the small/fast/datagram name
service infrastructure -- if you want to hold your guns on
this the proper response from the community is to tell you
to use something other than DNS, since you aren't really
using it anyway.
3) lots of clients, servers and firewalls between them prohibit
DNS over TCP anyway. ultra liberal free-text messages break
those nodes.
Again, not applicable. SPF doesn't require packets > 512B.
This, I think, is key. If strong evidence can be shown that creating
a new RR would not cause any significant delays, that would be the way
to go.
The biggest 'delay' is in getting application developers to work around
native resolver API limitations.
Wow. So a worldwide rollout to anything like most of the DNS servers
and resolvers for 100 million domains using a new RR is infeasible in
the near future in the real world, based on the deployed software out
there, or likely to get out there.
On 5/18/2004 9:06 AM, Pete Resnick sent forth electrons to convey:
In terms of using TXT records or not, I think Philip actually misses
the most important issue to me: wildcards. The discussion we were
having yesterday about how to deal with per-user records (and the
general problem of multiple sub-domain names mapping to a single
record) by using wildcards is almost a show-stopper in my mind. And
nobody who has proposed using TXT records with a "special" sub-domain
namespace (like _spf) has sufficiently explained to me how they're
going to address the wildcard problem.
What's the problem? If a a "special" sub-domain namespace (like _spf)
is used, there's still something in the result that indicates whether
it's an SPF record or not.
(A pointer to a log from yesterday would do the trick, perhaps; I logged
in and got cut off - T1 went down, as luck would have it.)