On Sat, 2007-06-02 at 04:04 -0400, Hector Santos wrote: > Steve Atkins wrote: > > What would "compliance" entail prior to universal, or at least > > widespread, support for the new RR by all stub resolvers and recursive > > resolvers? Or would you wait for that widespread support before > > releasing the spec? > > Steve, > > I am bit of a lost of what is so complex here. It is the lack of > understanding of the DNS technical compatibility issues that exist when > it comes to handling of new RR records? > > Until most, if not all, DNS servers, especially those with cached DNS > servers, support RFC 3597, "Handling of Unknown DNS Resource Record (RR) > Types", we will need a fallback on a TXT record concept. > > see RFC 3597, http://www.ietf.org/rfc/rfc3597.txt > > It is really isn't all that difficult. > > The bottom line is that there will be many systems with DNS servers and > domains that simply will not be able to work with a NEW RR and seriously > doubt DKIM is going to be the primary reason for most to begin changing > their setup or network in order to support the "near" reliable > propagation of NEW RR queries. > > There is really no choice here. To choose RR only, we are strategically > saying that we don't want older systems and all must upgrade. That > isn't a good strategy, never mind unrealistic. We are talking about a > huge population of DNS systems that simply do not have the capability of > handling a new RRs. > > If we want to maximize adoption, a TXT record is required.
Hector, I agree, and I think Steve was expressing the same. Use of TXT records means wildcards can not be used. Most would likely attempt to optimize a now more painful search by starting just below the TLD, especially when dealing with many labels. The DKIM WG might avoid resulting concerns by handling this downside. Avoidance could be achieved by a simple list established by IANA. This list could state "This domain supports a registry, and not other services." There should be plenty of motivation to enroll and use such a list. This list should also be fairly stable. Avoidance of these domains could be accomplished by "this is a registry" RR published by the registries. "Compliance" with such a mechanism would likely take longer than publishing a list. With many machines pumping out spam at rates approaching 1 gbit, and spam runs appearing to be millions wide, handling all this completely wasteful and often malicious traffic is not a trivial matter. At this point, critical Internet infrastructure is at its mercy. Whatever is done with DKIM must attempt to ensure this does not enable additional mischief. It seems ironic attempting to defend chronically porous OSs from the Internet, when its the Internet that needs defending. SSP can also permit a safe method to associate domains. In addition to preventing replay abuse, this mechanism could also help deal with the inevitable problem of bounce traffic containing broken DKIM signatures. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
