In <437AE3AE(_dot_)661C(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
Hallam-Baker, Phillip wrote:
You cannot support two record types. It is either or.
If you publish the same information through different records in the DNS
you will end up with a whole heap of race conditions caused by the
asymmetric cache behavior. You will also have administrators who put
different information in the different records.
This really isn't that much of a problem. All the cache inconsistency
problems mean is that receivers can't enforce a requirement that both
records MUST be identical. Both the old and new records MUST be valid
for all traffic sent during the transition period when the old is
being change to the new record. This is required due to DNS caching
anyway.
And there is not one single positive advantage that you get as a result.
Well, Andy seems to think there are advantages to using non-TXT
records, and I think some others do to. I'm not one of them. I think
that creating new records for DKIM is just as silly as it was for SPF.
On to what Frank wrote:
The SSP part is short enough to be mirrored in SPF, either
inline as "modifier", or as its own record using the same
record type 99.
I think this would be A Bad Idea because neither of the DKIM records
have a required magic number at the beinning of the record. This is
required to make sure that collisions aren't a problem. I think it
would be a good idea anyway, but the _domainkeys subdomain solves at
least some of the problem. It doesn't solve the problem of people
wildcarding SPF records, though.
-wayne
_______________________________________________
ietf-dkim mailing list
http://dkim.org