DANE SMTP behavior with inconsistent initial CNAME response

Viktor Dukhovni ietf-dane at dukhovni.org
Mon Dec 10 15:55:24 CET 2018



> On Dec 10, 2018, at 9:41 AM, Jan-Pieter Cornet <johnpc at xs4all.net> wrote:
> 
> I'm not suggesting to skip the CNAME query. I'm suggesting to not treat errors from that query as blocking for delivery, if there is no DNSSEC signed domain involved. Since the CNAME query is a new addition to the mail delivery landscape, you risk running into unexpected results from nameservers.

You should stop.  The CNAME record can't be a problem, it is only
made, *after* discovering that the A/AAAA records for the MX host,
involve a CNAME, and the response AD bit is 0:

	Q: mx.example.com. IN A ?
	R: mx.example.com. IN CNAME mx.example.net. ; AD=0
	   mx.example.net. IN A 192.0.2.1 ; AD=0

Only then does one make a CNAME query:

	Q: mx.example.com IN CNAME ?
	R: mx.example.com IN CNAME mx.example.net. ; AD=???

to discover the whether the original zone is signed,

> ... for which you give an excellent example yourself :)

My example shows why and how we *avoid* making the problematic
TLSA query, by making sure we know the security status of the
MX host's zone.  The text in the specification is not some
hastily constructed ad hoc choice.  Please consider the
possibility that there are good reasons for the choices made.

I am done with this topic for now.

-- 
	Viktor.



More information about the dane-users mailing list