"Knubben, Bart" bart.knubben@forumstandaardisatie.nl writes:

FYI Microsoft recently enabled outbound DANE verification by default for all Exchange Online customers: https://docs.microsoft.com/en-us/microsoft-365/compliance/how-smtp-dane-work...

Interesting. But not having detailed knowledge of Microsoft product names, I wonder how (or if?) "outlook.com" relates to this for inbound email?

I note that there still isn't any DS record for that zone.

Bjørn

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.

On 25 May 2022, at 8:03 am, Bjørn Mork bjorn@mork.no wrote:

Is this recommending using non-DANE domains for such contact points?

Not specifically. A skilled remote postmaster can figure out how to deliver email to a domain with DANE breakage, but indeed it may make sense to have a sub-domain with a non-DANE MX host for notices. That lowers the bar to getting the notices delivered.