On Dec 6, 2018, at 12:37 PM, Gael Roualland groualland@proofpoint.com wrote:
Agreed, we could look only at the validation result here. But assuming we get the same inconsistency in a secure way, then would that also be enough to apply DANE using the initial name as the TLSA domain ?
If the originally observed CNAME's fully expanded target is insecure, or there are no TLSA records with that name as the base domain, then you can indeed proceed to probe for TLSA records at the original name. If the full CNAME expansion result is secure, then necessarily the origin is also secure, so you don't even need to make the "initial CNAME" query.
mx.original.example. IN CNAME mx.step1.example. ; AD=(0|1) ... mx.step<i>.example. IN CNAME mx.step<i+1>.example. ; AD=(0|1) mx.step<N>.example. IN A 192.2.0.1 ; AD=(0|1)
[ Typically the resolver delivers the whole chain with a single AD bit value, so it is either "1" for all, or 0 for the whole response, but then you don't know where in the chain it stopped being secure. ]
a. "mx.step<N>.example" is secure (all the AD bits are 1), and associated secure TLSA RRset found.
* use "mx.step<N>.example" as TLSA base domain with corresponding TLSA records
b. expanded CNAME is secure (all AD bits are 1), and no secure TLSA associated with the expanded name.
* check for secure TLSA at original name
c. expanded CNAME is insecure (one of the AD bits is 0). Check security status of initial name via an "mx.original.example. IN CNAME ?" query. You only need the validation status (AD bit) not the result.
* If "insecure", done no DANE. * If "secure", look for TLSA RRset with "mx.original.example" as TLSA base domain. * If lookup failure (timeout, servfail whether DNSSEC-related or not), try a different MX host or defer.