On 25 May 2022, at 6:13 am, Jeremy Harris jgh@wizmail.org wrote:
Reading the article, it's outbound-only at this time. Inbound expected end 2022.
Yes, outbound-only at present. And the ETA for inbound may have drifted into 2023. Better late than never or poorly implemented.
Speaking of poorly implemented, this is a good time to review your processes for key/certificate rotation!
Any MX host for which you *first* deploy a new key/cert and only *then* update the DNS to set up a matching TLSA record (replacing its now outdated predecessor) is going to suffer periodic MX host outage lasting roughly as long as:
* The TTL of the previous TLSA record. * Plus the "refresh" time of any secondary nameservers that may still be serving older snapshots of the zone. * Possibly instead a minimum TTL configured on some resolvers.
This can be compounded by:
* Wildcard (single point of failure footgun) certificates replaced concurrently on all MX hosts. * Certificate rotation *without* bothering to update the DNS at all, waiting for remote sites to notify the operator of the resulting outage. * Use of DANE-TA(2) without ensuring: - A DNS name in the certificate that matches the TLSA base domain (generally equal to the MX hostname, unless it is a CNAME with the TLSA at the target) - That the leaf certificate is replaced before expiration - That the matching CA is explicitly present in your certificate chain file - That you don't also list retired CAs (e.g. Let's Encrypt "X3", see https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html)
Best practice is to use "3 1 1" TLSA records exclusively, pre-publishing a new TLSA record for the *next* key at least a few TTLs before it is deployed, with the stale TLSA record removed *after* the new certificate in place. See, https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html.
In sophisticated deployments with multiple certificates (e.g. RSA + ECDSA), you need concurrent "3 1 1" TLSA records for each of the underlying keys, both "current" and "next" before a rollover. See: https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html.
The "DANE Resources" links at: https://stats.dnssec-tools.org/explore/?. cover some of this ground.
Please also avoid WHOIS "privacy", and ensure working rolee contact addresses that are read by a human at least daily in:
* WHOIS records for the domain. * The DNS SOA "rname" field for the domain * Contact addresses on your website if applicable * Working "postmaster@" and/or "admin@" mailboxes.
If you do botch your TLSA records, it should be possible to reach someone to address the issue.