Subject: RE: [ietf-dkim] binary DKIM key

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 23 Mar 2006 11:40:33 -0800

> [mailto:[email-masked]] 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. 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Thu, 23 Mar 2006 12:50:16 -0800

> restarts via Dynamic DNS. This is simply not production level support for

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