The ADSP discussion of wildcard needs to be clarified, per
draft-levine-dkim-adsp-00:
Section 6.3., paragraph 1:
OLD:
Wildcards within a domain publishing ASP records, including but not
limited to wildcard MX records, pose a particular problem. While
referencing the immediate parent domain allows the discovery of an
ASP record corresponding to an unintended immediate-child subdomain,
wildcard records apply at multiple levels. For example, if there is
a wildcard MX record for "example.com", the domain
"foo.bar.example.com" can receive mail through the named mail
exchanger. Conversely, the existence of the record makes it
impossible to tell whether "foo.bar.example.com" is a legitimate name
since a query for that name will not return an "NXDOMAIN" error. For
that reason, ASP coverage for subdomains of domains containing a
wildcard record is incomplete.
NON-NORMATIVE NOTE: Complete ASP coverage of domains containing (or
where any parent contains) wildcards generally cannot be provided by
standard DNS servers.
NEW:
If a domain has valid wildcard MX, A, or AAAA records, then any
subdomain that does not otherwise exist according to [RFC4592] is a
valid mail domain. It is possible to add a wildcard TXT record
alongside a wildcard MX that will provide suitable ADSP records for
any domain chosen by an attacker, since if the wildcard synthesizes
chosen-name.example.com IN MX, it will then also synthesize
_adsp._domainkey.chosen-name.example.com IN TXT. However multiple
wildcard TXT records produce an undefined ADSP result, which means
you cannot also publish both ADSP records and records for any other
TXT-using protocol (such as SPF) for a wildcard domain.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html