Opportunistic DANE / TLS per host

Michael Grimm trashcan at odo.in-berlin.de
Sat Feb 7 22:18:17 CET 2015

Hi --

Very recently I started to implement and investigate DNSSEC and DANE at a test server (separate FreeBSD jail with postfix). I am using OpenDNSSEC for key rollover management and KSKs and ZSKs with 2048-bits and algorithm 8. While learning (Open)DNSSEC I made a mistake (misuse of OpenDNSSEC functionality) and screwed my chain of trust, thus making my test server "unknown" to DNS. Well, I learned how to deal with that, but that experience made me think about a "fallback" setup for hosts that somehow managed to screw their chain of trust as well.

http://www.postfix.org/TLS_README.html#client_tls_dane shows me an opt-in approach for opportunistic DANE (if I am not completely misunderstanding). 

What I want to implement is an opportunistic DANE approach with fallback to opportunistic TLS for "DANE broken" hosts, and implemented:

postconf -n | grep ^smtp_:
	smtp_dns_support_level = dnssec
	smtp_tls_security_level = dane
	smtp_generic_maps = pcre:/usr/local/etc/postfix/smtp_generic_maps
	smtp_tls_loglevel = 1
	smtp_tls_mandatory_protocols = !SSLv2 !SSLv3
	smtp_tls_note_starttls_offer = yes
	smtp_tls_protocols = !SSLv2 !SSLv3

plus "broken" hosts:
	transport_maps = pcre:/usr/local/etc/postfix/transport_maps

	/^example\.com/     opportunistic-tls

	opportunistic-tls       unix  -       -       n       -       -       smtp
	      -o syslog_name=postfix/otls
	      -o smtp_dns_support_level=enabled
	      -o smtp_tls_security_level=may

This is working on my test server, but before implementing that scheme on my productive server[1], I'd like to ask you experts out there: 

Do I miss something that might break my approach? Or, is there a more elegant way to implement a fallback oTLS?

Thanks and regards,

[1] only a handful users, but outgoing mail should not fail, never :-)

More information about the dane-users mailing list