DANE SMTP behavior with inconsistent initial CNAME response
ietf-dane at dukhovni.org
Thu Dec 6 18:55:55 CET 2018
> On Dec 6, 2018, at 12:37 PM, Gael Roualland <groualland at 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 220.127.116.11 ; 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
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.
More information about the dane-users