As of today I count 137620 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:
60764 domeneshop.no
43961 transip.nl
15734 udmedia.de
3040 bhosted.nl
1493 nederhost.net
904 ec-elements.com
431 core-networks.de
307 uvt.nl
301 bit.nl
287 omc-mail.com
The real numbers are surely larger, because I don't have access to
the full zone data for most ccTLDs, in particular .de, .nl and .no.
There are 2449 unique zones in which the underlying MX hosts are
found, this counts each of the above providers 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
(2613) of distinct MX host server certificates that support the
same ~137000 domains.
A related number is 4172 TLSA RRsets found for MX host TCP port 25.
This includes secondary MX hosts and domains none of whose primary
MX hosts have TLSA records.
The number of domains that at some point were listed in Gmail's
email transparency report is now 105 (this is my ad-hoc criterion
for a domain being a large-enough actively used email domain). Of
these, 56 are in recent reports (March 2017):
gmx.at jpberlin.de overheid.nl
nic.br lrz.de pathe.nl
registro.br mail.de wooniezie.nl
gmx.ch posteo.de xs4all.nl
open.ch ruhr-uni-bochum.de domeneshop.no
anubisnetworks.com tum.de webcruitermail.no
gmx.com uni-erlangen.de debian.orgmail.com unitymedia.de domainmail.orgpiratenexus.com web.de freebsd.orgpirateperfection.com enron.email gentoo.orgpre-sustainability.com octopuce.fr ietf.orgt-2.comcomcast.netnetbsd.orgtrashmail.comdd24.netnetcoolusers.orgxfinity.comgmx.netopenssl.org
bayern.de hr-manager.netsamba.org
bund.de t-2.nettorproject.org
elster.de xs4all.net minmyndighetspost.se
fau.de asp4all.nl skatteverket.se
gmx.de ouderportaal.nl
A different metric is how many of the DANE-enabled domains received
email from at least 10 Gmail senders in a recent 8 day interval.
Back in Dec/2016 I reported that ~2200 out of ~105k domains met
that criterion. This month, the number was ~3900 out of ~137k
domains. So it seems that a non-negligible fraction of the increase
is from real domains that receive email, and not just parked domains.
Of the ~137000 domains, 655 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 96 (~30 are recent additions that may be resolved soon,
the remaining ~60 are the for now stable population of broken
domains). This month I'm posting the list of the 44 underlying MX
hosts that serve these domains and whose TLSA records don't match
reality.
Hall of Shame:
mail.dipietro.id.au www.mtg.de mail.inu.nl
clubeararaquarense.org.br mx1.spamsponge.de mail.jekuiken.nl
mail.antiphishing.ch mail.nonoserver.info mail.myzt.nl
mail.digitalwebpros.com mx.datenknoten.me bounder.steelyard.nl
mail.dnsmadefree.com mx.giesen.me mx.wm.net.nz
demo.liveconfig.commail.castleturing.netbaobrien.orgny-do.pieterpottie.comdatawebb.dafcorp.netsmtp.copi.orgdiablo.sgt.comanubis.delphij.neteumembers.datacentrix.orgtusk.sgt.comdorothy.goldenhairdafo.net smtp2.amadigi.ovh
mx.bels.cz hs.kuzenkov.net webmail.headsite.se
johniez.cz oostergo.net protector.rajmax.si
mail.pksvice.cz ren.warunek.net arch-server.hlfh.space
srv01.101host.de mail.e-rave.nl mail.blackcherry-management.co.uk
mail.cdbm.de mail.hhsk.nl email.themcintyres.us
mail.manima.de box.inpoint-mailt.nl
The number of domains with bad DNSSEC support is 322. The top 10
DNS providers (by broken domain count) are:
52 axc.nl - Slated to be resolved
38 infracom.nl - Slated to be resolved
18 loopia.se
18 active24.cz
14 jsr-it.nl
12 rdw.nl
9 cas-com.net
8 metaregistrar.nl
6 tiscomhosting.nl
6 thednscompany.com
Around 60 of the broken domains have at least one working nameserver,
and so are email-reachable, given enough retries.
--
Viktor.
Summary: Mostly the same as last month, but new code made possible more
comprehensive coverage of domains with DNS issues. As a result,
the number of reported DNS issues has increased by almost 75%.
This is not an actual surge in DNS problems, rather just better
reporting of the existing (still improving) landscape.
The number of DANE-enabled domains that have also been sighted
on Google's email transparency report has increased from 114 to
115, while the number of DNS zones with TLSA-enabled primary MX
hosts has increased from 2668 to 2708. The domain count has
increased from 171738 to 172205.
A new type of TLSA record mismatch is starting to show up, so
far on just two MX hosts. Their RSA certificate chains match
their TLSA records, but their ECDSA certificate chains do not:
https://mail.sys4.de/pipermail/dane-users/2017-August/000416.htmlhttps://mail.sys4.de/pipermail/dane-users/2017-August/000417.html
As of today I count 172205 domains with correct DANE TLSA records for
SMTP. As expected the bulk of the DANE domains are hosted by 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:
68968 domeneshop.no
60617 transip.nl
18365 udmedia.de
6576 bhosted.nl
1809 nederhost.net
1331 yourdomainprovider.net
1003 ec-elements.com
517 core-networks.de
378 omc-mail.com
326 bit.nl
The real numbers are surely larger, because I don't have access to the
full zone data for most ccTLDs, especially .no/.nl/.de.
There are 2708 unique zones in which the underlying MX hosts are found,
this counts each of the above providers 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 (2933) of distinct MX host server
certificates that support the same ~172000 domains.
A related number is 3585 matching TLSA RRsets found SMTP MX hosts. These
cover 3708 distinct MX hosts (some of which clearly employ a shared
certificate).
The number of domains that at some point were listed in Gmail's email
transparency report is 115 (this is my ad-hoc criterion for a domain being
a large-enough actively used email domain). Of these, 59 are in recent
reports:
gmx.at jpberlin.de ouderportaal.nl
travelbirdbelgie.be lrz.de overheid.nl
nic.br mail.de pathe.nl
registro.br posteo.de xs4all.nl
gmx.ch ruhr-uni-bochum.de domeneshop.no
open.ch tum.de webcruitermail.no
switch.ch uni-erlangen.de debian.organubisnetworks.com unitymedia.de freebsd.orggmx.com web.de gentoo.orgmail.com egmontpublishing.dk ietf.orgsolvinity.com enron.email isc.orgtrashmail.com octopuce.fr netbsd.orgxfinity.comcomcast.netopenssl.orgxfinityhomesecurity.comdd24.netsamba.org
bayern.de gmx.nettorproject.org
bund.de hr-manager.net asf.com.pt
elster.de mpssec.net minmyndighetspost.se
fau.de t-2.net skatteverket.se
freenet.de xs4all.net t-2.si
gmx.de asp4all.nl
Of the ~172000 domains, 811 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 111.
Below is a list of the 69 underlying MX hosts that serve these domains
and whose TLSA records don't match reality:
Hall of Shame:
mail.dipietro.id.au mutt.lsexperts.de wfbrace.net
eumembers.stansoft.bg mail.manima.de mx2.wfbrace.net
mail.gna.ch mx1.spamsponge.de mx2.cbrace.nl
andbraiz.com mx.thorko.de mx3.cbrace.nl
mail.digitalwebpros.com mail.0pc.eu cinnamon.nl
mail.itsmine.com webmail.kassoft.eu smtp1.gblt.nl
demo.liveconfig.com mx.quentindavid.fr mail.initfour.nl
mx04.mykolab.com servmail.fr smtp1.lococensus.nl
intranet.nctechcenter.com upc.dircon.hu mail.myzt.nl
ny-do.pieterpottie.com mail.demongeot.info nuj-netherlands.nl
ma.qbitnet.com mail.nonoserver.info mx2.nuj-netherlands.nl
diablo.sgt.com kd2.io mail.solarisinternetgroep.nl
tusk.sgt.com node2.mxbackup.io bounder.steelyard.nl
stmics01.smia-automotive.com mail.laukas.lt vanderbijlict.nl
stmics02.smia-automotive.com mx.datenknoten.me mail.abanto-zierbena.orgerg.verweg.com mx.giesen.me beerstra.org
mx.bels.cz rootbox.me smtp.copi.org
gaia.nfx.cz lima.ahrain.neteumembers.datacentrix.org
mail.seslost.cz mail.castleturing.net smtp3.amadigi.ovh
mail.3c7.de horse.cherrypet.net mail.pasion.ro
mail.afaul.de mail.efflam.net mail.familie-sander.rocks
awesome-mail.de hs.kuzenkov.net mail.rostit.se
mail.denniseffing.de oostergo.net protector.rajmax.si
The number of domains with bad DNSSEC support is 649. Most of the increase
is from accenture.com domains, almost all likely parked, so the actual
impact on email delivery is probably small to none. The top 10 name server
operators with problem domains are:
145 accenture.com
61 jsr-it.nl
26 tiscomhosting.nl
26 active24.cz
21 firstfind.nl
18 bradesco.com.br
17 usda.gov
10 rotterdam.nl
10 loopia.se
10 fde.dk
Around 79 of the broken domains have at least one working nameserver,
and so are email-reachable, given enough retries. Only 5 of the
DNS-broken domains appear in historical Google Email transparency
reports:
tiviths.com.br
tre-ce.jus.br
tre-sp.jus.br
tse.jus.br
nsysu.edu.tw
The associated DNS lookup issues are:
_25._tcp.mailhost.bncr.fi.cr. IN TLSA ? ; ServFail
_25._tcp.barracuda.nsysu.edu.tw. IN TLSA ? ; ServFail
_25._tcp.lalavava.tse.jus.br. IN TLSA ? ; timeout
_25._tcp.mx.tiviths.com.br. IN TLSA ? ; timeout
_25._tcp.mandark.tse.jus.br. IN TLSA ? ; timeout
_25._tcp.dexter.tse.jus.br. IN TLSA ? ; timeout
[ See <https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08>,
Much of the TLSA non-response issue seems to be related to a
"feature" of Arbor Networks firewalls, that enables droping of
DNS requests for all but the most common RRtypes. Do not make
the mistake of enabling this firewall "feature". ]
The oldest outstanding DNS issue is another SOA signature issue
at truman.edu dating back to Nov/2014:
http://dnsviz.net/d/_25._tcp.barracuda.truman.edu/VGzORw/dnssec/
I hope some day soon they'll start missing email they care about
and take the time to resolve the problem.
--
Viktor.
Below a little text about TLS certificate agility and some pitfalls
herein (thanks to Viktor and Patrick for input and review):
The Transport Layer Protocol (TLS) supports the introduction of new key
algorithms for x509 certificates. For a long time, keys based on the RSA
algorithm were the only available choice. Nowadays, TLS also permits
keys based on elliptic curve algorithms such as ECDSA. Other, new
algorithms might follow in the future.
Modern algorithms promise same or better security with less CPU usage
and smaller key sizes. This makes the new algoritms interesting for
operators of TLS secured services. However older software (on client or
peer server side) might not support and understand the newer algorithms,
so both the new and the old need be configured for some transition
time. Ideally, both communicating endpoints will negotiate the best
algorithm (in terms of security and performance) supported by both
sides. The scheme of supporting multiple certificate key algorithms is
called certificate agility.
Care must be taken when multiple key algorithms are used in a TLS setup
together with DNS-based Authentication of Named-Entities (DANE) as
documented in RFC 7672
([https://tools.ietf.org/html/rfc7672.html]). With SMTP-DANE, data
authenticating the TLS certificates (the hashes of TLS certificate,
hashes of the public key, or the full certificates) are stored in DNS,
secured by DNSSEC. Upon connection, a delivering mail-server (MTA) will
recieve the certificate chain from the destination MTA and will try to
validate this certificate chain via the data stored in DNS as one or
more TLSA resource records. The TLSA records contain either information
on the leaf-node certificates (called DANE-EE(3)) or information about
the certification authority (DATE-TA(2)).
With DANE-EE(3) and TLS certificate agility in use, each distinct
certificate that is configured on the server side does require it's own
TLSA record containing either the hash of the certificate, hash of the
public key of the certificate or the certificate itself. With
DANE-TA(2), multiple TLSA-Records are only needed if the certificates
are issued by different certification authorities (care must be taken to
compare the CA keys in the certificate chain, as certain CA companies or
"brands" are using different certificate authorities to sign x509
certificates).
The postfix mail server supports certificate agility, in the example
below two certificates are configured, one based on RSA keys, and a 2nd
certificate using ECDSA keys:
,----
| # RSA certificate configuration
| smtpd_tls_key_file=/etc/postfix/tls/rsa-key.pem
| smtpd_tls_cert_file=/etc/postfix/tls/rsa-cert.pem
| # ECDSA certificate configuration
| smtpd_tls_eckey_file=/etc/postfix/tls/ecdsa-key.pem
| smtpd_tls_eccert_file=/etc/postfix/tls/ecdsa-cert.pem
`----
This configuration requires two separate DANE-EE(3) TLSA records in DNS,
one for RSA and one for the ECDSA certificate. If both certifcates are
issued from the same CA, only one DANE-TA(2) TLSA record is required.
OpenSSL 1.0.x does not handle multiple chain files gracefully, and so
both certificate chain files need to contain all the issuer CA
certificates needed to validate either end-entity (leaf) certificate.
This is fixed in OpenSSL 1.1.0.
The selection of which certificate algorithm to use is based on the TLS
handshake. Older TLS software prefers RSA over ECDSA, while some more
modern software will have a preference for ECDSA. Today most DANE
commandline tools (ldns-dane, gnutls-cli ...), as well as online DANE
services such as the DANE SMTP Validator ([https://dane.sys4.de]), are
only testing one certificate (based on the preference or configuration
of the underlying TLS library used to implement the tools). A missing
TLSA record can go unnoticed but can lead to rejection of mail. The DANE
SMTP Validator will be updated to check all possible TLS certificate key
algorithms.
---
Carsten Strotmann
