DANE verification enabled on MS Exchange Online
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...
For other DANE implementations, usage stats etc. see: https://github.com/baknu/DANE-for-SMTP/wiki
-- Best regards,
Bart Knubben Netherlands Standardisation Forum https://forumstandaardisatie.nl/netherlands-standardisation-forum
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
"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/05/2022 11:04, Bjørn Mork wrote:
I note that there still isn't any DS record for that zone.
Reading the article, it's outbound-only at this time. Inbound expected end 2022.
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.
Viktor Dukhovni ietf-dane@dukhovni.org writes:
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.
Is this recommending using non-DANE domains for such contact points?
Bjørn
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.
On Wed, May 25, 2022 at 08:29:07AM -0400, Viktor Dukhovni wrote:
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.
A sensible option would be to configure something along the lines of:
$TTL 1h $ORIGIN example.com. @ IN SOA ns1.example.com. tech.postmaster.example.com. ( ... ; serial 3600 ; refresh (1 hour) 1200 ; retry (20 minutes) 604800 ; expire (1 week) 1200 ; minimum (20 minutes) ) @ IN NS ns1 @ IN MX 0 smtp.example.com. ns1 IN A 192.0.2.1 ; smtp IN A 192.0.2.2 _25._tcp.smtp IN TLSA 3 1 1 ...current key hash... _25._tcp.smtp IN TLSA 3 1 1 ...future key hash... ; postmaster IN MX 0 postmaster postmaster IN A 192.0.2.2 ; same as smtp sans TLSA RRs
and to arrange to accept and read email for tech@postmaster.example.com, as well as publish the email address as the WHOIS technical contact.
participants (4)
-
Bjørn Mork -
Jeremy Harris -
Knubben, Bart -
Viktor Dukhovni