Hector Santos wrote:
----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
If DKIM deploys then DNSSEC will be pulled along in its wake
which in turn will drag deployment of the extension mechanism.
Making deployment of the extension mechanism a necessary
deployment condition creates a cycle of ungranted requests,
in other words a deadlock.
Just so I can better understand you, overall, due to the unreliability of
proper operations in a wide, generalized DNS server network, you do not
support the introduction of a new RR for DKIM. Would that be correct?
Also, if it was done, I guess there it would require there be a migration
concept and thus we would have two records; a RR and TXT record. Thus, from
a client (DKIM implementation) standpoint, it would behave in a try RR
First, fallback to TXT second concept. Right? If so, would you consider
this to be too much overhead, making it impractical to expect clients to
operate in this mode?
There's a different situation for key records and
policy/practice/(petunia?) records. The choice of whether to use a new
RR or a TXT key record should be retrieved is something that can be
represented in the signature (the query type, q=, tag has been suggested
which makes sense).
The retrieval of "P" records is more of a problem, since in general
there's nothing in the message to tell the verifier what to look for.
This argues in favor of not having two ways to do this. Alternatively,
a verifier could cache (even beyond the TTL of the DNS records) the type
of record favored by a given domain, as a hint to what to look for first.
NOTE WELL: This list operates according to