The real problem is the policy record.
We can probably get the key record transition to happen because it will
coincide with rollout of new algorithm. Probably dsa2048 with 64 byte
signatures. We can just about do them with bas64 but I would argue that dkim
deployment will drive dnssec which will solve the rr introduction problem (not
least because we should have our record defined before dnssec deploys.
The priority should be deploy dkim.
-----Original Message-----
From: Michael Thomas [mailto:mike(_at_)mtcc(_dot_)com]
Sent: Thu Mar 23 13:05:11 2006
To: Hallam-Baker, Phillip
Cc: Douglas Otis; IETF-DKIM
Subject: Re: [ietf-dkim] binary DKIM key
Hallam-Baker, Phillip wrote:
The problem here is that there is a big difference between what some people
choose to believe and reality. I do not see how any competent network op is
going to enter DKIM RRs if they are going to require changing their DNS
server to BIND (a huge issue for an active directory shop) or using the
proposed kludge of injecting the new RRs into the server each time it
restarts via Dynamic DNS. This is simply not production level support for
new record types.
While I don't dispute the overall jist of your post, it should be noted
that situation with DKIM is better off than MARID because a domain can
always delegate the _domainkey subdomain to something that's a bit more
cooperative. This was, in fact, how we finally managed to get our
enterprise management IT folks to support us -- they're being highly
allergic to anything beyond A records in their database.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html