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
