[ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree

[Eliot Lear]

Dave,

1402 and 1534 were specifically mentioned and discussed in Philly in 
Jim's presentation 
<http://www3.ietf.org/proceedings/08mar/slides/dkim-0.pdf>.  In fact, 
between the two they've been discussed at multiple meetings.    We know 
this because the mechanism has changed over time and was presented as it 
changed.  You can continue to traipse through the minutes of previous 
meetings (my own recollection and the minutes confirm 
<http://www.ietf.org/proceedings/07mar/minutes/dkim.txt> that is that 
the group spent time on this very issue in Prague).  You did not 
object.  My own recollection of the Prague discussion was that we 
specifically considered the positives and negatives of tree walking as 
well as a domain existence query, but perhaps the audio i lying around 
if you want to go to more detail.

Putting aside that procedural issue, the fundamental basis for your 
concern is that there are two independent systems that have no basis for 
interdependency.  But your premise is false, and the issue is 
specifically raised in the current -03 draft, here:

>    2.  _Verify Domain Exists._ The host MUST perform a DNS query for a
>        record corresponding to the Author Domain (with no prefix).  The
>        type of the query can be of any type, since this step is only to
>        determine if the domain itself exists in DNS.  This query MAY be
>        done in parallel with the query made in step 2.  If the result of
>        this query is an "NXDOMAIN" error, the algorithm MUST terminate
>        with an appropriate error.
>        
>           NON-NORMATIVE DISCUSSION: Any resource record type could be
>           used for this query since the existence of a resource record
>           of any type will prevent an "NXDOMAIN" error.  MX is a
>           reasonable choice for this purpose is because this record type
>           is thought to be the most common for likely domains, and will
>           therefore result in a result which can be more readily cached
>           than a negative result.

No A record required, as Frank and I mentioned earlier.

Perhaps I have missed some text that you are referring to.  Could you 
correct me?

Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20080408/26e447ae/attachment.html