In <[EMAIL PROTECTED]> Frank Ellermann <[EMAIL PROTECTED]> 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
