DANE verification enabled on MS Exchange Online

[Viktor Dukhovni]

> On 25 May 2022, at 6:13 am, Jeremy Harris <jgh at 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.

-- 
	Viktor.