DANE for STMP is supported in postfix as well. DANE is more popular in Europe currently than the newly specified MTA-STS. Larger providers tend to prefer MTA-STS because it does not mandate the use of DNSSEC.
Where "larger" really means Google and Yahoo, others as you now see are less zealous about MTA-STS as the main way forward (there's little sign of broad adoption beyond a small number of the largest providers).
For Google, part of the issue is that signing "google.com" where the MX hosts live is a non-trivial endeavour given all the DNS-based load-balancing kit that's deployed at scale. That can be solved by e.g. switching the MX hosts to another domain, e.g. "smtp.goog" which is signed, and already has mx[1-4].smtp.goog as alternative MX hosts for the same domains (gmail.com and all the G-suite hosted ones).
All that's required is TLSA RRs for these, and presto-magic, inbound DANE for Google-hosted domains that are signed and have designated these MX hosts (some already have, despite lack of official guidance from Google that these are supported, nagging for such guidance continues...).
And of course gmail.com could be signed without having to sign google.com, so given willpower to get it done, technically they have a simple way forward.
For yahoo.com, there's no separation between the email domain and the (does anybody still care about it) website. So DANE SMTP for yahoo.com could be more difficult, but again not insurmountable, if they still have any resources left to get new things done. If they're only on life-support, then probably not any time soon. (I'm still waiting for native IPv6 from Verizon Fios...)
Another significant obstacle is perhaps internal politics. There is sadly some quasi-religious zeal (feels like in-group vs. out-group territoriality) around "dislike" of DNSSEC. True believers in the faith are wiser and more prescient than us unenlightened masses, and have been effective barriers to progress in more than one organization.
There's of course work to be done to improve DNSSEC usability (with significant progress in e.g. BIND 9.16 automating key rollover, not just resigning), especially the interface between registrant and registrar, where CDNSKEY/CDS support would remove barriers to KSK management.
It would be great to see more domains upgrade from RSA-2048 KSK + RSA-1024 ZSK to ECDSA P-256, or at least at a 1280-bit RSA ZSK, with adequately frequent (~90 day or so) ZSK rollover. For RSA, algorithms 5 and 7 which use SHA-1 signing (now deprecated) need to be upgraded to 8 or 10 which use SHA2.
Internet-scale infrastructure changes take effort and time, and if you're not actively participating, at least try to not get in the way.
Support for DANE in software doesn't mean anything. It's always been the case that you could stand up an MTA that used DNSSEC. What matters is how many users are protected by DNSSEC, which is a function of which domains actually deploy it. Virtually no domains are signed (it's less than 1% of American domains, a number that has dropped in some of the previous years).
The USA is not always the best practice to emulate. Microsoft's SMTP servers host mail for at least 284k (today's count) signed domains. When they enable inbound DANE, these (likely more by then) will be protected by DNSSEC and DANE.
The rear-view mirror is not always the best guide to the road ahead.
It looks like they're growing steadily, from those graphs, until you look at the Y axis and realize it's been cropped to look like it's growing steadily. In fact, in DNSSEC-signed zones in .COM have gone down in some recent years.
In fact, DNSSEC is deployed in a tiny fraction of all .COM zones (something close to 1%), virtually none of which are significant, as you can quickly discover by feeding a list of top zones (the Moz 500 is easy to download) through "host -t ds".
Note that none of Microsoft's domains are even signed. What this announcement really says is that Office 365 will at some point in the next 12 months stop implementing Microsoft's policy of actively impeding people from using DNSSEC.
Wrong: They've announced plans to also implement inbound DANE. Given that the domains in question are all child domains of mail.protection.outlook.com, they'll have to sign outlook.com some time before end 2021 in order to support inbound DANE.
Obvious: This requires some planning and perhaps also fork-lift replacement of the old (out-of-spec) DNS load-balancers. The fact that it'll take some time is not unexpected.
Ciao, as you may already know, I don't usually bother trying to debate religious zeal.
8 comments
[ 2.5 ms ] story [ 24.8 ms ] threadFor Google, part of the issue is that signing "google.com" where the MX hosts live is a non-trivial endeavour given all the DNS-based load-balancing kit that's deployed at scale. That can be solved by e.g. switching the MX hosts to another domain, e.g. "smtp.goog" which is signed, and already has mx[1-4].smtp.goog as alternative MX hosts for the same domains (gmail.com and all the G-suite hosted ones). All that's required is TLSA RRs for these, and presto-magic, inbound DANE for Google-hosted domains that are signed and have designated these MX hosts (some already have, despite lack of official guidance from Google that these are supported, nagging for such guidance continues...).
And of course gmail.com could be signed without having to sign google.com, so given willpower to get it done, technically they have a simple way forward.
For yahoo.com, there's no separation between the email domain and the (does anybody still care about it) website. So DANE SMTP for yahoo.com could be more difficult, but again not insurmountable, if they still have any resources left to get new things done. If they're only on life-support, then probably not any time soon. (I'm still waiting for native IPv6 from Verizon Fios...)
Another significant obstacle is perhaps internal politics. There is sadly some quasi-religious zeal (feels like in-group vs. out-group territoriality) around "dislike" of DNSSEC. True believers in the faith are wiser and more prescient than us unenlightened masses, and have been effective barriers to progress in more than one organization.
There's of course work to be done to improve DNSSEC usability (with significant progress in e.g. BIND 9.16 automating key rollover, not just resigning), especially the interface between registrant and registrar, where CDNSKEY/CDS support would remove barriers to KSK management.
It would be great to see more domains upgrade from RSA-2048 KSK + RSA-1024 ZSK to ECDSA P-256, or at least at a 1280-bit RSA ZSK, with adequately frequent (~90 day or so) ZSK rollover. For RSA, algorithms 5 and 7 which use SHA-1 signing (now deprecated) need to be upgraded to 8 or 10 which use SHA2.
Internet-scale infrastructure changes take effort and time, and if you're not actively participating, at least try to not get in the way.
The rear-view mirror is not always the best guide to the road ahead.
In fact, DNSSEC is deployed in a tiny fraction of all .COM zones (something close to 1%), virtually none of which are significant, as you can quickly discover by feeding a list of top zones (the Moz 500 is easy to download) through "host -t ds".
In reality, DNSSEC is moribund.
Wrong: They've announced plans to also implement inbound DANE. Given that the domains in question are all child domains of mail.protection.outlook.com, they'll have to sign outlook.com some time before end 2021 in order to support inbound DANE.
Obvious: This requires some planning and perhaps also fork-lift replacement of the old (out-of-spec) DNS load-balancers. The fact that it'll take some time is not unexpected.
Ciao, as you may already know, I don't usually bother trying to debate religious zeal.