On Thu, Dec 06, 2018 at 04:42:44PM +0100, Gael Roualland wrote:
- some of these serve a valid zone content such as (A):
domain.tld. IN MX 1 mail.domain.tld. mail.domain.tld IN A 192.168.1.1
- others server a "parking" like zone (B):
*.domain.tld. IN CNAME domain.tld. domain.tld. IN A 192.168.1.2
None of these zones are signed.
A careful DANE implementation will generally not employ DANE for unsigned domains.
- 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.
- 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.
- 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.
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.
AFAIK, this particular case is not covered by the RFC, and we're trying to assess if degrading to Opportunistic TLS in that case instead of temporary failing could actually introduce some security flaw in the process.
You should be fine.
It seems to me that for an attacker to be able to purposely return such inconsistent answers, he would need to be able to spoof answers if zones are not signed (like here) or have either control of the zone DNS key or of the MTA's resolver, both which would allow other ways to skip DANE.
I'd like to get your opinions on this. Does that sound safe ? What do other implementations do in that particular case ?
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?