[ This assumes you are willing to trust your issuer CA to not
misissue certificates for your domain, and include the CA
certificate in your server chain file. ]
One approach to making sure that DANE TLSA records are less likely
to fail that should work well for sites using CA-issued certificates
is to publish both "3 1 1" and "2 1 1" TLSA records:
mx.example. IN TLSA 3 1 1 <digest of server public key>
mx.example. IN TLSA 2 1 1 <digest of immediate issuer public key>
* The "3 1 1" record protects against "expiration" accidents, and
unexpected changes in the issuer's public key (if new certificate
chain deployment is automated).
* The "2 1 1" record protects against key rotation errors should a
a new server private key be deployed without updating the TLSA
RRs. Provided the new certificate is issued by the same CA
is unexpired, ... the "2 1 1" record will match.
With a bit of monitoring to ensure that both records match,
simultaneous failure of both is much less likely.
This even makes it possible to avoid pre-deployment DNS TLSA records
updates when rotating certificates, provided at least one of the
issuer public key or the server public key is unchanged in the new
chain.
In particular, this is the best practice with Let's Encrypt
issued SMTP server certificates, as explained in:
https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certifi…
--
Viktor.
As of today I count 105264 domains with correct DANE TLSA records
for SMTP. As expected the bulk of the DANE domains are hosted the
handful of DNS/hosting providers who've enabled DANE support in
bulk for the domains they host. The top 10 MX host providers by
domain count are:
42300 domeneshop.no
33519 transip.nl
15205 udmedia.de
1748 bhosted.nl
1292 nederhost.net
897 ec-elements.com
387 core-networks.de
300 uvt.nl
266 bit.nl
227 omc-mail.com
The real numbers are surely larger, because I don't have access to
the full zone data for any ccTLDs, and in particular .de and .nl.
There are 2269 unique zones in which the underlying MX hosts are
found, this counts each of the above registrars as just one zone,
so is a measure of the breadth of adoption in terms of servers
deployed. Alternatively, a similar number is seen in the count
(2349) of distinct MX host server certificates that support the
same ~105000 domains.
Of the ~105000 domains, 825 have "partial" TLSA records, that cover
only a subset of the MX hosts. While this protects traffic to some
of the MX hosts, such domains are still vulnerable to the usual
active attacks via the remaining MX hosts.
The number of domains with incorrect TLSA records or failure to
advertise STARTTLS (even though TLSA records are published) stands
today at 75 (~25 are recent additions that will likely be resolved
soon, the remaining ~50 are the long-term stable population of
broken domains).
The number of domains with bad DNSSEC support is 405. The top 10
DNS providers (by broken domain count) are:
58 axc.nl
39 infracom.nl
22 registrar-servers.com
19 loopia.se
19 active24.cz
16 forpsi.net
12 jsr-it.nl
12 cas-com.net
9 ovh.net
9 ignum.com
Around 100 of the broken domains have at least one working nameserver,
and so are email-reachable, given enough retries.
The number of domains that at some point were listed in Gmail's
transparency report is 95 (this is my ad-hoc criterion for a domain
being a large-enough actively used email domain). Of these 44 are
in the most recent report:
gmx.at lrz.de xworks.net
conjur.com.br mail.de asp4all.nl
registro.br posteo.de bhosted.nl
gmx.ch ruhr-uni-bochum.de overheid.nl
open.ch uni-erlangen.de xs4all.nl
anubisnetworks.com unitymedia.de domeneshop.no
gmx.com web.de debian.orgmail.com enron.email freebsd.orgtrashmail.com octopuce.fr gentoo.orgxfinity.comcomcast.netietf.org
bund.de dd24.netnetbsd.org
fau.de gmx.netopenssl.org
gmx.de hr-manager.netsamba.org
jpberlin.de t-2.nettorproject.org
kabelmail.de xs4all.net
In September of 2016 I asked a contact at Google to count how many
of the domains in the survey received correspondence from multiple
Gmail users. Back then the number was 1,827 out of 56k domains.
More recently the number is 2,266 out of ~105k domains.
I don't have any way to measure how many domains enable DANE outbound
but aren't using DNSSEC for their own domain or publishing TLSA
records. It is easy to do, just fire up a local validating resolver,
adjust /etc/resolv.conf to list only 127.0.0.1 and/or ::1, and add
a couple of lines to main.cf.
--
Viktor.
