DANE SMTP behavior with inconsistent initial CNAME response
groualland at proofpoint.com
Thu Dec 6 18:37:09 CET 2018
On 6/12/18 17:16, Viktor Dukhovni wrote:
>> 1) MX lookup for the domain: returns "1 mail.domain.tld." (from zone A)
> This is unsigned, and so you could stop DANE processing at that
> point. However, some DANE implementations (e.g. recent Postfix
> versions) still employ DANE even for domains with "insecure" MX
> records, when the selected MX host is in a signed zone.
This is what we offer as an option too (default on) and which is enabled
in that case.
However we could still have a similar behavior if the original domain is
signed, but the MX hostname is in a non-signed zone or an alias to a
>> 2) A/AAAA lookup for "mail.domain.tld": returns "A 192.168.1.1" through
>> "CNAME domain.tld." (from zone B)
> Yes, that can happen, what a mess. The destination domain's DNS
> is broken, and DANE or not, it is lucky to get any mail at all.
>> 3) Since the A reply is insecure and is from a CNAME alias, as per
>> §2.2.2 of the RFC we issue an explicit CNAME request on
>> "mail.domain.tld." to check if this is secure: this returns a NODATA
>> answer (from zone A)
> So long as the NODATA answer is "insecure", the fact that it denies
> the CNAME's existence is tolerable, the sole purpose of the CNAME
> lookup is probe for DNSSEC in the original zone, and an "insecure"
> NODATA shows the zone to be unsigned.
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
>> In that case, our implementation considers that having a NODATA answer
>> to a CNAME that it received previously in a former response is
>> suspicious, and temporary fails this delivery attempt as if we hit a DNS
> I would suggest that it is OK to be less "suspicious". While zone
> content can vary between nameservers, the DNSSEC status of a domain
> should be robust.
> Your instinct is reasonable. It is OK to continue with this domain.
> By the way, it is news to me that Proofpoint supports DANE.
> Congratulations and welcome to the club! Do you support both
> DANE-EE(3) and DANE-TA(2)? The most recent opensource Sendmail
> snapshot I can find still has fairly minimal DANE support. Is there
> somewhere a public description of DANE support in Proofpoint?
I'm referring to the Cloudmark Security Platform product. Cloudmark was
acquired by Proofpoint a year ago. I can't speak for DANE support status
in other Proofpoint products.
We do support DANE-EE and DANE-TA, and try to adhere to the
specification as much as possible. We have a blog post about it at 
but that doesn't go into technical implementation details.
More information about the dane-users