As you're may be aware, I actively promote adoption of DANE SMTP, many
thanks to everyone who's moved forward with DANE SMTP deployment!
That said, I also always stress that, when deploying DANE SMTP,
*monitoring* must come first, and publishing of DANE TLSA records
second. If your DANE TLSA deployment is unmonitored, it will some day
fail, with you being the last to know that something is wrong when some
email fails to arrive on time or at all. Unmonitored security is a
ticking time-bomb.
Please implement monitoring of your DANE TLSA records vs. the live
certificate chain through regular probing of your MX hosts (I'd suggest
hourly if not more often for more critical servers). Of course you
also need to have good automation of the certificate rollover process
so that normally TLSA records aren't out sync with the certificates
even during a rollover.
If you don't yet have monitoring in place, the below could be a useful
building block for your monitoring scripts.
The "danesmtp" shell (bash) function can take an optional explicit IP
address to connect to, so you can test each of the IP addresses of a
host in turn:
danesmtp () {
local OPTIND=1 opt
local -a rrs sslopts
local rr i=0 host addr
while getopts a: opt; do
case $opt in
a) addr=$OPTARG
case $addr in *:*) addr="[$addr]";; esac;;
*) printf 'usage: danesmtp [-a addr] host [ssloption ...]\n'
return 1;;
esac
done
shift $((OPTIND - 1))
host=$1
shift
if [[ -z "$addr" ]]; then
addr="$host"
fi
sslopts=(-starttls smtp -connect "$addr:25"
-verify 9 -verify_return_error
-dane_ee_no_namechecks -dane_tlsa_domain "$host")
rrs=( $(dig +short +nosplit -t tlsa "_25._tcp.$host" |
grep -Ei '^[23] [01] [012] [0-9a-f]+$') )
while (( i < ${#rrs[@]} - 3 )); do
rr=${rrs[@]:$i:4}
i=$((i+4))
sslopts=("${sslopts[@]}" "-dane_tlsa_rrdata" "$rr")
done
( sleep 1; printf "QUIT\r\n" ) | openssl s_client -brief "${sslopts[@]}" "$@"
}
--
Viktor.
