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
non-signed name.
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.
Indeed...
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
domain ?
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
error.
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.
OK.
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?
Thanks.
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 [1]
but that doesn't go into technical implementation details.
Gaël.
[1] https://blog.cloudmark.com/2017/03/27/dane-and-email-security/