DANE SMTP behavior with inconsistent initial CNAME response

[Gael Roualland]

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.

Thanks,

Gaël.