Over the past few IETF meetings, I have proposed various methods for
publication and query of DKIM information. Some of these have
significant problems (for which I apologize) and others have significant
overhead. The assumption here is that a new RR type is being used, but
there are variations on this that could be done with prefixed TXT
records (although possibly with additional queries, to interpret
NXDOMAIN responses properly). These include:
Option 1: Publish wildcards and "shadow records". The domain publishing
SSP will need to publish a DKIMP [maybe we should call it SSP?] record
at the domain level, and alongside all other records in the zone (what I
call "shadow records). This could be done manually, but hopefully tools
will come along that will help this. If there is a wildcard record in
the zone (such as a wildcard MX), a wildcard DKIMP will need to be
published as well. No need for a wildcard DKIMP record otherwise. The
goal here is that, if SSP exists, a query anywhere within the zone will
return either the SSP record or a NXDOMAIN response (never a NODATA).
Option 2: The domain publishing SSP will publish a DKIMP record at the
domain level, and alongside all multiple-level label (e.g., foo.bar)
records in the zone as well as for any subdomains to which it wishes to
propagate DKIM policy. If there is a wildcard record in the zone (such
as a wildcard MX), a wildcard DKIMP will need to be published as well.
If a query results in a NODATA response, the verifier would query the
parent domain (only one level). If a NODATA response to the parent
domain is received, the message is considered non-suspicious. Note that
this option hasn't been fully vetted, and may have problems yet.
Option 3: As presented at IETF 68, upward queries would be performed if
a NODATA response is required until the verifier gets to a TLD (or
something that acts like one).
Discussion: Option 3 is simplest for the publisher, but likely to be
considered unacceptable due to the potentially unbounded querying of
higher-level domains, and possible load on root and/or TLD servers.
Option 1 is the most compliant with DNS directorate wishes, but probably
requires special tooling (in the form of "meta-wildcards" as proposed by
Phill) in order to be practical for large zones, and is otherwise prone
to error. Option 1 also requires a new record for every label (e.g.,
hostname) in the zone, so it could add up to a lot of additional
records, although most would probably never be referenced (and would
never occupy cache space). Option 2 is an attempt at a compromise; is
it workable?
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html