Mark Delany wrote:
On Thu, Mar 30, 2006 at 10:09:24AM -0800, Jim Fenton allegedly wrote:
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).
As a practical matter, I don't see how this can actually work to
eliminate the DKK then TXT sequence because you don't know the
capabilities of the verifiers. Can they fetch DKK? No one knows.
There are (at least) two reasons that the verifier might not be able to
(1) Their DNS infrastructure doesn't allow them to fetch a DKK record.
(2) The verifier itself doesn't support DKK lookups.
There seem to be sharp disagreements on (1), whether this is a problem
with current products, and how much legacy infrastructure there might be
that does not support new RRs. I don't have any data at all on this.
Does anyone have, or know where we could get, hard facts on what
products and versions would have a problem with a new RR (e.g., BIND
version<x.xx, etc.)? I have heard comments that some domains are
running very old versions of BIND, but I don't know which ones are
actually a problem.
(2) is much less of a problem; it is an incompatibility in the sense
that an old verifier wouldn't understand new signatures, but we're
running into several of those. If the IETF DKIM specification says that
support for the DKK RR is a MUST implement for verifiers, it should be
safe for any signer that is using other aspects of the new specification
to use only the DKK RR (assuming the infrastructure issue above isn't an
obstacle). I would argue that the specification should also require, or
at least strongly recommend, verifier support for TXT as well, due to
the deployed base of TXT keys and the desire for DKIM to be able to
verify signatures from older signers.
NOTE WELL: This list operates according to