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.
And there is not one single positive advantage that you get as a result.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Mark Delany
Sent: Tuesday, November 15, 2005 1:21 PM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] DKIM DNS record types
On Tue, Nov 15, 2005 at 12:05:15PM -0600, wayne allegedly wrote:
In <437A1D33(_dot_)3090605(_at_)mtcc(_dot_)com> Michael Thomas
<mike(_at_)mtcc(_dot_)com> writes:
wayne wrote:
Why the three months between the SSP I-D and the DNS
recourse record?
Can't we just use a TXT RR clone the way SPF did?
The main reason is so that we don't have to b64 encode the public
key. Beyond that, it may well be just a drop in TXT clone of the
rest.
Won't people have to b64 encode the public key anyway to
put it into
their zone file?
Are you talking about the representation as input to a DNS
content server or are you talking about the binary
representation of the RR?
The former may well be b64, but that doesn't imply the latter.
I think there are strong reasons to just keep it simple.
Just use a
clone of the TXT record for the DKK and DKP records.
Define this in
the -base and -ssp documents and be done with it. The SPF
spec does
it this way and it is really very trivial.
All the implementations are going to have to support the parsing of
TXT records anyway, so adding support for TXT record clones saves a
lot of extra work. That, and we can cut out an entire I-D and 3
months out of the development process.
These are reasonable arguments. The complexity of a Selector
when converted to a binary representation is significant.
There are at many types that need to be encoded: Flags,
timestamps, email addresses, key-data, key-type and some are
variable length.
None of the encoding is rocket-science, but above and beyond
the cost-benefit issue is the very real risk of loss of flexibility.
Mark.
_______________________________________________
ietf-dkim mailing list
http://dkim.org
_______________________________________________
ietf-dkim mailing list
http://dkim.org