Re: New DNS record issue.

> > "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
> > > In effect what you are saying here is that SPF is going to be so 
important
> > > that it can in effect claim TXT for exclusive use.
> "wayne" <wayne(_at_)midwestcs(_dot_)com> wrote:
> > Just those with the magic string at the beginning that says "v=spf1 ".
What Wayne said.  TXT is not dedicated to any application - not even SPF - 
but what SPF proposes to do is legal and fine and cool.

--guillaume(_at_)filion(_dot_)org wrote:

> Imagine that a domain has four TXT RRs, one of those if spf (for example
> altavista.com). Your client needs to query the 4 TXT RRs for that domain,
> compare the first chars of each record to "v=spf1 " and decide which one,
> if any, is the spf record.
>
> With the change that Phillip is proposing, the client would only need to
> query the _spf subdomain (i.e. _spf.altavista.com), if you recieve
> something, you know that you have a SPF record and you can parse it.

Hey!  I actually wrote those 4 TXT records so I feel like I can jump in 
here. :)
That is a lot of text and you can probably argue that it's wasteful, but 
it's still less than 512 bytes and you still get all the response in one 
packet.  I put the extra TXT in there to explain to anyone who looks at it 
WHY the spf record is there and what it is intended to do.
I *don't* think this means that TXT and SPF are naturally in conflict.  I 
think they are very complementary.

> From a design point of view, this is much cleaner, and from a practical
> point of view, if we multiply that that several billion emails a day and
> you start to see a big difference in ressources saving.
>
> It's pretty obvious to me that this is a better way of doing things, what
> I'm not totally convinced of is that is a big enough of a problem to
> change the specification.

As Wayne said before, _spf.mydomain.name WAS the original spec and it was 
changed.  I approve of the change for the reasonse Meng stated: people and 
servers will trip over the _ and even if it is perfectly legal *now* there 
is a time when it wasn't, so people get stuck on that.
I strongly *disapprove* of having to add another name for philosophical 
reasons.  The SPF information for "altavista.com" belongs to 
"altavista.com" just like the MX records do - I don't want to add a 
different *name* when what I really want is a new *type* of data for the 
same *name*.
Anyway, both approaches would have worked and I would probably have 
supported _spf if it made it to the final form.  I think the mydomain.name. 
IN TXT "v=spf1 ***" is a cleaner approach and I like it better, and I think 
it has a better chance of being more widely adopted, even if it's not the 
most clever thing imaginable with the technology available.  Sometimes the 
simple solution is better.

Having said all that, what we REALLY need is an SPF RR type so we can query 
for SPF resources.  I think this will eventually happen.  TXT is a good 
temporary measure, but eventually IETF will get around to approving it (or 
something much like it) and we can leave our TXT records behind, to be used 
for obscure stuff propeller-heads like me might use it for like "what's my 
netmask again".
Once SPF becomes a recognized record type, it would probably be redundant 
to say
 _spf.mydomain.name.  IN  SPF  "v=spf1 ***"
I can see admins of the future asking "I wonder why they have SPF on the 
line three times? and what's underscore mean, again? :)"

> > There are other systems that co-opt TXT records and most of them use a
> > magic string also.  It is incumbent on those systems that overload the
> > use of the TXT record to make sure that they don't conflict with past
> > or future usage, and I think SPF accomplishes that just fine with the
> > version string.
> It's reasonnable to hope that there won't be conflicts with future
> protocols by using the magic string, but more CPU and bandwidth will be
> used than with Phillip's proposal.

I'm going to make a guess that the chance of other TXT records already 
existing is rather low.  We are still getting questions from domain owners 
like "What is a TXT record and how do I make one?  Does DynDNS support 
them?"  If most (90%) of domains don't have additional TXT that is not SPF 
data, there is not really that much waste.  (I'll take out the extra TXT 
for altavista.com if it bothers you :)
On the other hand, I could quibble about adding 5 bytes of _spf. to every 
spf request... but that concern would probably be less important in the 
long run as well.
Cheers!
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>

-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡