Mircea Purdea wrote:
In light of the newly published 'draft-allman-dkim-ssp-02', I'm
curious to hear what plans the rest of you guys have regarding
implementation.
I think it's probably a little early to do any serious implementation
except on a very experimental basis, since the draft hasn't gotten much
review from other than the authors yet. I do appreciate that you are
thinking in that direction, however.
I admit I haven't had time to fully digest it yet, but the thing that
struck me immediately is the introduction of the new DKIMP DNS RR;
this might 'for most intents' be a 'dedicated TXT RR', but fact is,
just adding a TXT RR with DKIMP syntax does not make a DKIMP RR (does
it?). So, deployment of SSP2 actually requires the modification of
existing DNS servers and resolvers, doesn't it?
No, a TXT RR with DKIMP syntax is not a DKIMP RR. A different RR type
(to be assigned) MUST be used. This allows the query to avoid the use
of a distinguishing name prefix (such as _policy._domainkey, which was
used before with the TXT record). This in turn has the advantage that a
single query can, in principle at least, determine both the existence of
the domain and the presence of an SSP record.
BIND 9, at least, can publish new RR types using the TYPExxxx syntax
(e.g., TYPE1010) to define the records in their zone files. There may
very well be other servers and resolvers which require modification to
handle new RR types, but DNS needs extensibility so this needs to change
anyway. Also, while SSP deployment is highly desirable, a domain that
can't publish and/or query is at a disadvantage, but is still able to
use -base DKIM.
-Jim
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev