[ietf-dkim] SSP issues TXT and no wildcards.
dotis at mail-abuse.org
Sat Jun 2 03:24:05 PDT 2007
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?
> 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.
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
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
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.
More information about the ietf-dkim