Re: DNS RRtypes: creating a new RRtype

Hmm, I have to agree with you that SPF will get much more widespread 
acceptance if you're just adding a simple TXT record. I would even 
venture as far to say that SPF would recieve its strongest opposition if 
it *were* to use a different RR-type. As you said, in one case you're 
simply adding an entry to a working DNS server, while in another you've 
got to update your DNS server just to utilize it and many people are 
lazy. This does not, however, mean I think a new RR-type isn't the 
"correct" solution. But based on the facts presented to me, I concede 
that TXT is the best route to go for now.
It's a tough call, really. It's having to decide between whether SPF 
will get more critics from byte-hogs or lazy folks. It'd be nice if 
there was a surefire way of satisfying them both.

Mark Lentczner wrote:

> While I see the attractiveness of a new RR type from a theoretical 
> perspective, I think the TXT record approach is far more practical.  
> And since we would like to SPF deployed as fast as possible, practical 
> should rule.
> Here are my arguments for using TXT records under a reserved subdomain 
> (like "_smtp_client"):
> 1) Many more sys admin.s will be willing to simply add TXT records, 
> than have to update their software.  (Or if they happen to be running 
> BIND9, turn on some hidden poorly documented feature.)  Many other 
> domains don't have control over the software their DNS runs on.  If 
> you're using one of the many registrars that also provide DNS service, 
> you can probably add TXT records, but not new RR types.
> 2) Do we really know about the ability existing and deployed DNS 
> servers, other than BIND9, to handle new RR types?  Can they handle 
> them easily in their configuration files?  TXT records are almost 
> certainly supported in every DNS server, and easy to configure.
> 3) The fact that RR records might be more compact isn't really 
> relevant any more:  To the mail servers that will be querying SPF, a 
> 128 byte response vs. a 64 byte response isn't going to make any 
> difference.  While I come from an era of counting every byte and 
> cycle, I've come to realize that in today's Internet, ease of 
> interoperability is worth doubling or tripling your data size.  Even 
> SMTP is a text base protocol!
> 4) Actually, using TXT records in a subdomain is probably a much 
> better, sustainable way to leverage DNS for future services: Adding RR 
> types has a very high cost. Organizations must get involved in 
> arbitrating the numbers (cost of collision is high), servers must be 
> updated to handle them, and even those servers that support arbitrary 
> RR types would eventually want to be updated to support nice 
> configuration for popular new RR types.  On the other hand, TXT 
> records in a subdomain is cheap.  Only the subdomain namespace needs 
> to be arbitrated, and that can reasonably be done late (collision is 
> unlikely, and cost low).  We can use "_smtp_client" and pretty much 
> know that we won't be conflicting with anything.
> Sorry if these arguments have already been made and/or refuted before 
> - I realize that I'm coming a little late to this discussion.
>     - Mark
>
> -------
> 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.txt
> To unsubscribe, change your address, or temporarily deactivate your 
> subscription, please go to 
> http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡


-------
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.txt
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡