Steve Atkins wrote:
On Jun 1, 2007, at 7:30 PM, Arvel Hathcock wrote:
(2) SSP record type (TXT vs. something new). Only 4 messages in
discussion, mostly saying "if you support TXT, don't bother with
anything else." Again, no clear consensus.
If a new RR can solve the wildcard issue and we feel that this is a
significant issue worth solving (or at least addressing) then perhaps
we should create a system that looks for a new RR first and failing
that, falls back to TXT.
I don't think the "if you support TXT, don't bother with anything
else" position is correct. If we come out with a spec that states
"SSP clients must query for new RR first, then TXT" senders would be
right to expect compliance.
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.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html