Re: DNS RRtypes: creating a new RRtype

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;±¤Ö¤Íµø?¡