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.
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
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.
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.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/