|
[ietf-dkim] Single Organization TXT Lookup with Multiple TXT Records Result
2007-06-02 07:40:10
Doug,
If I catch your drift, I will be opposed to any IANA or 3rd party
"registry" concept for SSP. Not sure how that relates to RR vs TXT
records SSP question.
Anyway, wild card searches is something, IMO, most systems are simply
not going to need. And if required for a larger domain, they simply can
create multiple TXT records.
This can be solved very simply with a SSP syntax that has multiple text
records concept or one long, with tag or fields or attributes for each
sub-domain, if necessary. Right now, a TXT lookup will return all TXT
records. So all we need is a single organization domain lookup to
obtain all its sub-domain policies.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Douglas Otis wrote:
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
|
|