Frank Ellermann wrote: > Stephen Farrell wrote: > > >> ssp-04 did revise the wildcard text, but not exactly as suggested >> in the issue, nor am I clear about whether the new text satisfies >> the couple of people (Eliot, Frank) who commented in the thread. >> > > The version in ssp-04 IMO misses the following wildcard TXT points: > (1) There is no explicitly specified way to identify an ADSP record, > when it comes as one of several TXT records in a q=txt reply. > In the terminology of an IAB draft ADSP defines no TXT subtype. > (2) Even if ADSP would do this a set of wildcard TXT records for > various purposes (compare RFCs 1464, 4406, 4408, and 3920bis) > might be too long for UDP. > (3) As a consequence of (1) ADSP likely doesn't work for wildcards. > As a consequence of (2) the WG apparently refused to fix (1). > A simple "MUST start with 'dkim='" (or similar) could fix it. >
There is a potential issue when looking up ADSP for a non-existent subdomain of a domain having a wildcard TXT record (such as an SPF record). For example, if there is a wildcard TXT record for *.example.com, and the domain nonexistent.example.com does not exist at all (there are no RRs of any type associated with the label 'nonexistent'), then the lookup for _adsp._domainkey.nonexistent.example.com will return the wildcard record(s). It would therefore be desirable to have some indicator in the TXT record that this is, indeed, a DKIM ADSP record. A requirement such as (3) for both publication and checking of the start of the record should do the job. I'm not too worried about (2). If there is an ADSP record, it will take precedence over any wildcard record(s) and be returned in its place. The only use of wildcards by ADSP is defined in section 6.3 which says that multiple wildcard TXT records produce an undefined ADSP result. I'm not sure that has to be the case if we define a TXT subtype as above, but in any case I'd discourage the publication of wildcard ADSP records, even though they might work in some instances described in section 6.3. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
