ietf-dkim
[Top] [All Lists]

Re: Issue 1382 (was: Re: [ietf-dkim] New Issue: New resource record type)

2006-10-16 09:35:53
In <45339562(_dot_)5070407(_at_)cs(_dot_)tcd(_dot_)ie> Stephen Farrell 
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> writes:

I don't personally know if SSP records are in any way different
from key records, but it does seem to be the case that there is
some general opposition to (re-)using TXT.

This very discussion came up on the namedroppers list not too long
ago.

There are many DNS folks that seem to think that because they have
created RFCs that allow for new record types to be created "easily",
and because some name server software has been updated to support
this, and because there have been a few new RR types created for
systems that have almost zero deployment, that there really isn't much
problem with making everyone use a new RR type.  Basically, because
the low-level stuff is there, the problem has been solved.

Scott, on the other hand, has long dealt with a very high level
problem of keeping track of which DNS hosters actually support even the
long established TXT record type.  Most likely due to SPF deployment,
the number of hosters that support TXT records have increased
significantly, but there are still lots that don't.  Support for other
DNS records, such as NS or SRV records is almost non-existent.

So, if you run your own DNS and use non-braindead up-to-date
resolvers, supporting new RR types is easy.  If you are a smaller
domain that uses something like godaddy to host your DNS and use
Microsoft products, you are in for a very rough time.


I guess it largely depends on who the target users of DKIM is.  If it
is mostly large companies that send lots of email, a new RR type isn't
going to be too much of a problem.  If the target is for everyone, a
new RR type is a showstopper.



-wayne
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>