New DNS Record Types - was HELO versus MAILFROM results

At 05:42 PM 5/4/2005 -0400, Radu Hociung wrote:

> In a way, if it is a duplicate of TXT, there's no point spending the
> effort to create a new RR.
I did some research on the choice between defining a new record type vs 
using a TXT record in a subdomain like _spf.example.com.  There have been 
far too many vague statements about this topic, and it is difficult to get 
definite answers.  If anyone has some solid info, I would sure appreciate 
seeing it.  Apparently, it's a hot-potato topic.  I have a private 
communication with one of the "DNS folks", but he was not willing to 
discuss it in the mailing list, for fear of starting a flame war.
Here is what I've learned (additions and corrections are welcome, I'm not 
an expert):
1) Some of the "DNS folks" have a general preference for using a new record 
type, and avoiding the _trick.  The reasons for that preference are 
detailed in draft-iab-dns-choices-01.txt  Basically, if you use the _trick, 
you cannot also use wildcards, like _spf.*.example.com.
2) Another problem with the _trick is that (quoting Wayne from the 
namedroppers mailing list on 11 Jan 2005) "we found too many DNS hosting 
services that didn't allow the underscore to be entered into the web 
pages.  This is kind of a delema for those hosting services.  Yes, an 
underscore is perfectly valid for a domain name, but it isn't valid for a 
host name."
3) Both CSV and DomainKeys use the _trick extensively.  Since the "CSV 
folks" are very close to the "inner circle", I conclude that using it is 
not such a terrible thing that it will kill a proposal.
4) Wildcards have a number of limitations that people have lived with for 
years.  See "DNS and BIND", 4th ed., p.503 "Wildcards".  One more 
limitation, implicit in the text, but not listed, is that you can't put a 
wildcard in the middle, like _spf.*.example.com.  If that is OK in your 
application, then item 1 above is not a problem.
5) There is no performance penalty in using subdomains like 
_client._smtp.example.com as long as the subdomains are all part of the 
same zone file.
Here are my partially formed opinions:

1) DNS has a few flaws in its design.  Records have a useless "class" 
attribute, but no "name" attribute, which would have been much more 
useful.  Using the "type" attribute as a name is OK if it is an important 
new application, and you have time to register a new type, but it is 
inappropriate if you need to create new records quickly, and the names of 
those records would only clutter the list of registered types.  See below 
for an example.  Imagine a compiler that didn't allow named variables, only 
a proliferation of variable types.
2) SPF made a mistake in abandoning the _trick.  Now we have to deal with 
overcrowded TXT records, and a migration headache from TXT to SPF.
3) We will dig ourselves deeper into this hole if we encourage the use of 
wildcards.  It seems to me that wildcards aren't really necessary with 
email authentication, or even desirable.  If some subdomain of mydomain.com 
wants to run its own public mail servers, they should create their own DNS 
records specifically authorizing those servers.

Example:
In the example general-purpose authentication record from my draft, I have 
the information for a domain in summary form:
svc=S1:A,M2:A,H1+:B  dmn=QR1,SPF1+5,DK2

The "variable names" here are S1, M2, H1, QR1, SPF1, and DK2.  Names which 
have a trailing + require additional records.  The location of those 
records is determined using the _trick. ( _H1.mydomain.com, 
_SPF1.mydomain.com ).  There is no need to register a new variable 
name.  The guy setting up the authentication record for mydomain simply 
decides there isn't enough room in one record for everything he would like 
to include in the information from service H1.  So he puts a + after the 
name H1, and adds a new record at _H1.mydomain.com.  We cannot do this 
adding records "on the fly" if we have to register new record "types" and 
wait for nameservers worldwide to be upgraded to recognize those types.

--
Dave
************************************************************     *
* David MacQuigg, PhD      email:  dmquigg-spf at yahoo.com      *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                   9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.              Tucson, Arizona 85710        *
************************************************************     *