[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Douglas Otis
After talking to Olafur, he was fairly convincing about the
battle that might ensue, and that things have changed with
respect to the roadblocks that exist for newer RR types.
Developing a new RR type for the DKIM binary key may be the
path of the least resistance.
The problem I have here is that I find it rather hard to believe that the
capabilities of the Windows DNS server have changed since the day Lyons
showed use the source code in the MARID working group. The Windows DNS
server is very widely used, something like 30% of sites. The code for saving
a zone file has a comment that basically says 'drop unknown RRs on the
floor'.
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.
The other point of concern here is that attempts to distribute the same
information through two different paths leads to the likelihood of race
conditions, particularly since the DNS has pervasive caching.
The path of least resistance may well be to propose a parallel binary RR.
The DNSEXT group is not going to listen to any level of proof.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html