DANE SMTP behavior with inconsistent initial CNAME response
groualland at proofpoint.com
Fri Dec 7 11:39:45 CET 2018
On 6/12/18 18:57, Viktor Dukhovni wrote:
> 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
Yes, this is what we currently do.
> 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.
That's what I was referring to. So this confirms that validation is
enough whether "secure" or "insecure".
We'll thus relax our implementation not to enforce a valid CNAME reply
but just check validation status on lookup success.
More information about the dane-users