From ietf-dane at dukhovni.org Wed May 2 05:40:44 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 2 May 2018 03:40:44 +0000 Subject: Update on stats 2018-04 Message-ID: <20180502034042.GT29327@mournblade.imrryr.org> Summary: The DANE domain count is now 205,351. Much of the increase is the result of better (though still incomplete) coverage of the ".no" TLD, but some is due to the more gradual steady increase in the breadth of adoption. I hope to broaden the coverage further in May. The number DNSSEC domains in the survey stands at 6,017,669, thus DANE TLSA is deployed on 3.41% of domains with DNSSEC. Data graciously provided by Gmail shows that 16,170 of the DANE domains have received recent email from at least 5 senders. And 2449 (vs. 1,542 a year ago out of a then total 137,244 domains) of the domains have received at least 50 recent messages. As of today I count 205,351 domains with correct SMTP DANE TLSA records at every primary MX host that accepts connections[1]. 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: 90580 domeneshop.no (result of better .no coverage) 67122 transip.nl 19107 udmedia.de 6142 bhosted.nl 1787 nederhost.nl 1214 yourdomainprovider.net 878 hi7.de (name change from ec-elements.com) 751 surfmailfilter.nl 549 core-networks.de 456 omc-mail.com The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.nl/.de. Speaking of countries, the IPv4 GeoIP distribution of DANE-enabled MX hosts shows the below top 10 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented): 1374 DE, Germany 922 US, United States 490 NL, Netherlands 358 FR, France 157 GB, United Kingdom 125 CZ, Czech Republic 88 CA, Canada 65 SE, Sweden 56 CH, Switzerland 49 SG, Singapore IPv6 is still comparatively rare for MX hosts, and the top 10 countries by DANE MX host IPv6 GeoIP are (same top 6). 782 DE, Germany 474 US, United States 286 NL, Netherlands 221 FR, France 94 GB, United Kingdom 76 CZ, Czech Republic 37 SE, Sweden 26 SG, Singapore 24 CH, Switzerland 16 IE, Ireland There are 3264 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. The number of published MX host TLSA RRsets found is 4675. These cover 4933 distinct MX hosts (some MX hosts share the same TLSA records through CNAMEs). The number of domains that at some point were listed in Gmail's email transparency report is 132 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 71 are in recent reports: gmx.at ruhr-uni-bochum.de politie.nl travelbirdbelgique.be tum.de uvt.nl nic.br uni-erlangen.de xs4all.nl registro.br unitybox.de domeneshop.no gmx.ch unitymedia.de handelsbanken.no open.ch web.de webcruitermail.no anubisnetworks.com dk-hostmaster.dk aegee.org gmx.com egmontpublishing.dk debian.org mail.com tilburguniversity.edu freebsd.org solvinity.com insee.fr gentoo.org trashmail.com octopuce.fr ietf.org xfinity.com comcast.net isc.org xfinityhomesecurity.com dd24.net netbsd.org xfinitymobile.com dns-oarc.net openssl.org bayern.de gmx.net samba.org bund.de hr-manager.net torproject.org elster.de mpssec.net asf.com.pt fau.de t-2.net handelsbanken.se freenet.de xs4all.net minmyndighetspost.se gmx.de bhosted.nl skatteverket.se jpberlin.de boozyshop.nl t-2.si lrz.de ouderportaal.nl mail.co.uk mail.de overheid.nl govtrack.us posteo.de pathe.nl Of the ~205000 domains, 1502 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 258. Some of these also have MX hosts that don't have broken TLSA records, so mail can still arrive via the remaining MX hosts. Goging forward I'm no longer listing the problem MX hosts here. Instead, I am contributing data to the github project that tracks domains with DANE failures: https://github.com/danefail/list Please open issues or pull requests if you domains that are not listed. To avoid getting listed, please make sure to monitor the validity of your own TLSA records, and implement a reliable key rotation procedure. See: https://dane.sys4.de/common_mistakes http://imrryr.org/~viktor/ICANN61-viktor.pdf http://imrryr.org/~viktor/icann61-viktor.mp3 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 After eliminating parked domains that do not accept email of any kind, the number of "real" email domains with bad DNSSEC support stands at 110. The top 10 name server operators with problem domains are: 8 tse.jus.br 8 psb1.org 8 nazwa.pl 7 active24.cz 5 tiscomhosting.nl 4 ignum.com 4 glbns.com 4 centralpark.se 4 army.mil 4 1cocomo.com No domains all whose nameservers have broken denial of existsnce appear in historical Google reports. -- Viktor. [1] Some domains deliberately include MX hosts that are always down, presumably as a hurdle to botnet SMTP code that gives up where real MTAs might persist. I am not a fan of this type of defence (it can also impose undue latency on legitimate email). However, provided the dead hosts still have TLSA records, (which don't need to match anything, just need to exist and be well-formed) there's no loss of security. From fuckspam at wheres5.com Sun May 13 10:55:53 2018 From: fuckspam at wheres5.com (Hoggins!) Date: Sun, 13 May 2018 10:55:53 +0200 Subject: tlsa binary fails with certificate error Message-ID: <57cff8d9-7a6b-5b8b-fe26-90c9d46a5605@wheres5.com> Hello list, Not sure this is the right place to post, maybe I'd better mail the maintainer of the package, but you might have encountered the same issue. I've always published TLSA records for my domains/subdomains, and using an automated (Cron) job to do this, invoking the tlsa script (provided by the hash-slinger package on my Fedora machines). Now for about a few weeks now, the tlsa script fails, complaining with the following error message: Could not verify local certificate: no start line. Traceback (most recent call last): ? File "/usr/bin/tlsa", line 889, in ??? genRecords(args.host, args.protocol, args.port, chain, args.output, args.usage, args.selector, args.mtype) NameError: name 'chain' is not defined I'm using LetsEncrypt for my certificates, and I can't see what changed recently. I'm running the tlsa script against a concatenated (intermediate + domain certificate) PEM file, and it has always worked just fine. During my investigations, I found that an "openssl verify" will fail on the file, saying "unable to get local issuer certificate". I have no way to tell if this has always failed, or if this is new behavior. I'd be glad to hear if you have any thoughts about my issue. ??? Thanks! ??? ??? Hoggins! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From ietf-dane at dukhovni.org Sun May 13 18:10:42 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 13 May 2018 12:10:42 -0400 Subject: tlsa binary fails with certificate error In-Reply-To: <57cff8d9-7a6b-5b8b-fe26-90c9d46a5605@wheres5.com> References: <57cff8d9-7a6b-5b8b-fe26-90c9d46a5605@wheres5.com> Message-ID: > On May 13, 2018, at 4:55 AM, Hoggins! wrote: > > Not sure this is the right place to post, maybe I'd better mail the > maintainer of the package, but you might have encountered the same issue. This list is a reasonable place to share experiences with the use of DANE-related tools. Though you may have trouble receiving email from this list, until your TLSA records are correct. The list MTA may be doing DANE-validation, and your TLSA records have been incorrect since ~28/Apr/2018. [This reply is also Bcc'd to you directly, just in case]. > Now for about a few weeks now, the tlsa script fails, complaining with > the following error message: > > Could not verify local certificate: no start line. This suggests that the file it is trying to use is either not a PEM file, or contains no certificate. A PEM certificate is enclosed between two lines of the form: ----- BEGIN CERTIFICATE ----- ----- END CERTIFICATE ----- Double check that the file exists and is well-formed. > I'm using LetsEncrypt for my certificates, and I can't see what changed > recently. I'm running the tlsa script against a concatenated > (intermediate + domain certificate) PEM file, and it has always worked > just fine. This should be OK, but you're posting the syntax you're using, and not showing the file permissions, what id the cron job is running as, ... > During my investigations, I found that an "openssl verify" will fail on > the file, saying "unable to get local issuer certificate". To verify a chain file, try: $ chainfile=chain.pem # adjust appropriately $ rootCA=root.pem # adjust appropriately $ openssl verify -untrusted $chainfile -CAfile $rootCA $chainfile the "-untrusted ..." option makes the intermediate certificates in the chain file available for verification and of course the root CA needs to be locally available. Mind you, for DANE-EE(3) you really don't need to verify your certificate, so this is likely a distraction. > I have no way > to tell if this has always failed, or if this is new behavior. Your TLSA records used to be correct until ~28/Apr/2018 > I'd be glad to hear if you have any thoughts about my issue. Please review the slides (and if you wish audio) from ICANN61 talk, that recommends a more robust key rotation approach. Stick with "3 1 1" rather than "3 1 2", in DNS smaller replies work better, and SHA2-256 is plenty secure. http://imrryr.org/~viktor/ICANN61-viktor.pdf http://imrryr.org/~viktor/icann61-viktor.mp3 Also see the listing for your domains at: https://github.com/danefail/list/blob/master/dane_fail_list.dat please do read the DANE misconfiguration notices sent when the DANE survey finds problems, you were notified on 28/Apr, 30/Apr and 05/May. -- Viktor. From fuckspam at wheres5.com Tue May 22 11:05:24 2018 From: fuckspam at wheres5.com (Hoggins!) Date: Tue, 22 May 2018 11:05:24 +0200 Subject: tlsa binary fails with certificate error In-Reply-To: References: <57cff8d9-7a6b-5b8b-fe26-90c9d46a5605@wheres5.com> Message-ID: <4cd9ca1b-c862-fd1e-023f-008b9e19e9e8@wheres5.com> Hello Viktor, Thank you for your answers. I've performed all the checks I could, the certificates are well formed ("openssl x509 -in cert.pem -text -noout" succeeds), I'm starting to think there may be a problem with my Python version. At least I'm pretty sure that the issue comes from a system update on both the ones I'm using for generating the signatures : on an old system, I'm successfully generating the records with the exact same files. I'm really not a Python guy, so I tried some ugly debugging with "print" placed here and there to check what was going on. Here are the differences between a "working" and a "non working" system (both using Python 2.7, although the binaries don't have the same checksums), inside routine getLocalChain() : -- non working system : Fedora 28, python2-libs-2.7.15-1.fc28.x86_64 ??? ??? ??????? while True: ??????????????? cptr = m2.x509_read_pem(bio._ptr()) ??????????????? if not cptr: ??????????????????????? break ??????????????? chain.append(X509.X509(cptr, _pyfree=1)) ??? ??? ??? ??? print chain ??????? if not chain: ??? ??? If I put the "print chain" inside the while loop, I get the correct chain array (one pass with only one item, and second pass with two items, output is as expected). *BUT* ??? ??? ??????? while True: ??????????????? cptr = m2.x509_read_pem(bio._ptr()) ??????????????? if not cptr: ??????????????????????? break ??????????????? chain.append(X509.X509(cptr, _pyfree=1)) ??? ??? print chain ??????? if not chain: ??? ??? I the "print chain" is placed after the loop, *it does not print anything*, so the script will eventually complain about "chain" not being defined. -- working system : Fedora 24, python-libs-2.7.13-2.fc24.x86_64 With this system and Python version, both tests are functional : either inside the loop or after the loop, I get something in the "chain" variable. So that makes me look at the Python version, but I could be wrong. I'm open to discussion. And as you were saying Viktor, it is confirmed here : since my servers have bad DANE signatures, communicating on this list is quite complicated for me. Thank you ! ??? Hoggins! Le 13/05/2018 ? 18:10, Viktor Dukhovni a ?crit?: > >> On May 13, 2018, at 4:55 AM, Hoggins! wrote: >> >> Not sure this is the right place to post, maybe I'd better mail the >> maintainer of the package, but you might have encountered the same issue. > This list is a reasonable place to share experiences with the use of > DANE-related tools. Though you may have trouble receiving email from > this list, until your TLSA records are correct. The list MTA may be > doing DANE-validation, and your TLSA records have been incorrect since > ~28/Apr/2018. [This reply is also Bcc'd to you directly, just in case]. > > >> Now for about a few weeks now, the tlsa script fails, complaining with >> the following error message: >> >> Could not verify local certificate: no start line. > This suggests that the file it is trying to use is either not a PEM > file, or contains no certificate. A PEM certificate is enclosed > between two lines of the form: > > ----- BEGIN CERTIFICATE ----- > ----- END CERTIFICATE ----- > > Double check that the file exists and is well-formed. > >> I'm using LetsEncrypt for my certificates, and I can't see what changed >> recently. I'm running the tlsa script against a concatenated >> (intermediate + domain certificate) PEM file, and it has always worked >> just fine. > This should be OK, but you're posting the syntax you're using, and not > showing the file permissions, what id the cron job is running as, ... > >> During my investigations, I found that an "openssl verify" will fail on >> the file, saying "unable to get local issuer certificate". > To verify a chain file, try: > > $ chainfile=chain.pem # adjust appropriately > $ rootCA=root.pem # adjust appropriately > $ openssl verify -untrusted $chainfile -CAfile $rootCA $chainfile > > the "-untrusted ..." option makes the intermediate certificates in > the chain file available for verification and of course the root CA > needs to be locally available. Mind you, for DANE-EE(3) you really > don't need to verify your certificate, so this is likely a distraction. > >> I have no way >> to tell if this has always failed, or if this is new behavior. > Your TLSA records used to be correct until ~28/Apr/2018 > >> I'd be glad to hear if you have any thoughts about my issue. > Please review the slides (and if you wish audio) from ICANN61 talk, > that recommends a more robust key rotation approach. Stick with > "3 1 1" rather than "3 1 2", in DNS smaller replies work better, and > SHA2-256 is plenty secure. > > http://imrryr.org/~viktor/ICANN61-viktor.pdf > http://imrryr.org/~viktor/icann61-viktor.mp3 > > Also see the listing for your domains at: > > https://github.com/danefail/list/blob/master/dane_fail_list.dat > > please do read the DANE misconfiguration notices sent when the > DANE survey finds problems, you were notified on 28/Apr, 30/Apr > and 05/May. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From ietf-dane at dukhovni.org Tue May 22 16:11:15 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 22 May 2018 10:11:15 -0400 Subject: tlsa binary fails with certificate error In-Reply-To: <4cd9ca1b-c862-fd1e-023f-008b9e19e9e8@wheres5.com> References: <57cff8d9-7a6b-5b8b-fe26-90c9d46a5605@wheres5.com> <4cd9ca1b-c862-fd1e-023f-008b9e19e9e8@wheres5.com> Message-ID: <47BF2857-0D63-4F93-B81B-480A28B31C59@dukhovni.org> > On May 22, 2018, at 5:05 AM, Hoggins! wrote: > I think I see the bug: > -- non working system : Fedora 28, python2-libs-2.7.15-1.fc28.x86_64 > > > while True: > cptr = m2.x509_read_pem(bio._ptr()) > if not cptr: > break > chain.append(X509.X509(cptr, _pyfree=1)) You're telling Python it owns the certificate object reference and should free it when no longer needed. Then add the certificate to the chain, but this call may not bump the certificate reference count. > print chain Here you print the chain. And the certificate itself goes out of scope and is freed, the chain no longer holds a valid reference. > If I put the "print chain" inside the while loop, I get the correct > chain array (one pass with only one item, and second pass with two > items, output is as expected). > > *BUT* > > > while True: > cptr = m2.x509_read_pem(bio._ptr()) > if not cptr: > break > chain.append(X509.X509(cptr, _pyfree=1)) > print chain > if not chain: > > > I the "print chain" is placed after the loop, *it does not print > anything*, so the script will eventually complain about "chain" not > being defined. I think all the certificates are freed leaving no valid references in the chain. In any case, you should fix your TLSA records to be correct first, and then fix the script... Perhaps "_pyfree = 0" would work better. If the script does not run forever, but is just a cron job, freeing memory just slows it down... -- Viktor. -- Viktor. From fuckspam at wheres5.com Tue May 22 16:39:16 2018 From: fuckspam at wheres5.com (Hoggins!) Date: Tue, 22 May 2018 16:39:16 +0200 Subject: tlsa binary fails with certificate error In-Reply-To: <47BF2857-0D63-4F93-B81B-480A28B31C59@dukhovni.org> References: <57cff8d9-7a6b-5b8b-fe26-90c9d46a5605@wheres5.com> <4cd9ca1b-c862-fd1e-023f-008b9e19e9e8@wheres5.com> <47BF2857-0D63-4F93-B81B-480A28B31C59@dukhovni.org> Message-ID: <1545d4ff-f718-9d55-c6cb-94c935011eb1@wheres5.com> Hello Viktor, I have published the correct TLSA records (generated with my "old" system) this morning, they are fixed for now. Le 22/05/2018 ? 16:11, Viktor Dukhovni a ?crit?: > >> On May 22, 2018, at 5:05 AM, Hoggins! wrote: >> > I think I see the bug: > >> -- non working system : Fedora 28, python2-libs-2.7.15-1.fc28.x86_64 >> >> >> while True: >> cptr = m2.x509_read_pem(bio._ptr()) >> if not cptr: >> break >> chain.append(X509.X509(cptr, _pyfree=1)) > You're telling Python it owns the certificate object reference > and should free it when no longer needed. Then add the certificate > to the chain, but this call may not bump the certificate reference > count. > >> print chain > Here you print the chain. And the certificate itself goes out of > scope and is freed, the chain no longer holds a valid reference. Actually when inside the loop, chain is not empty, it's only outside of it that it seems to be freed. > >> If I put the "print chain" inside the while loop, I get the correct >> chain array (one pass with only one item, and second pass with two >> items, output is as expected). >> >> *BUT* >> >> >> while True: >> cptr = m2.x509_read_pem(bio._ptr()) >> if not cptr: >> break >> chain.append(X509.X509(cptr, _pyfree=1)) >> print chain >> if not chain: >> >> >> I the "print chain" is placed after the loop, *it does not print >> anything*, so the script will eventually complain about "chain" not >> being defined. > I think all the certificates are freed leaving no valid > references in the chain. > > In any case, you should fix your TLSA records to be correct first, > and then fix the script... Perhaps "_pyfree = 0" would work better. > If the script does not run forever, but is just a cron job, freeing > memory just slows it down... Changing _pyfree=1 to _pyfree=0 did not help, unfortunately. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From ietf-dane at dukhovni.org Tue May 22 16:49:02 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 22 May 2018 10:49:02 -0400 Subject: tlsa binary fails with certificate error In-Reply-To: <1545d4ff-f718-9d55-c6cb-94c935011eb1@wheres5.com> References: <57cff8d9-7a6b-5b8b-fe26-90c9d46a5605@wheres5.com> <4cd9ca1b-c862-fd1e-023f-008b9e19e9e8@wheres5.com> <47BF2857-0D63-4F93-B81B-480A28B31C59@dukhovni.org> <1545d4ff-f718-9d55-c6cb-94c935011eb1@wheres5.com> Message-ID: <9A23DEEB-26E4-4FFC-A283-48074C16AA19@dukhovni.org> > On May 22, 2018, at 10:39 AM, Hoggins! wrote: > > Hello Viktor, > > I have published the correct TLSA records (generated with my "old" > system) this morning, they are fixed for now. Yes, I see that too. I've removed your domains from: https://github.com/danefail/list > > Le 22/05/2018 ? 16:11, Viktor Dukhovni a ?crit : >> >>> On May 22, 2018, at 5:05 AM, Hoggins! wrote: >>> >> I think I see the bug: >> >>> -- non working system : Fedora 28, python2-libs-2.7.15-1.fc28.x86_64 >>> >>> >>> while True: >>> cptr = m2.x509_read_pem(bio._ptr()) >>> if not cptr: >>> break >>> chain.append(X509.X509(cptr, _pyfree=1)) >> You're telling Python it owns the certificate object reference >> and should free it when no longer needed. Then add the certificate >> to the chain, but this call may not bump the certificate reference >> count. >> >>> print chain >> Here you print the chain. And the certificate itself goes out of >> scope and is freed, the chain no longer holds a valid reference. > > Actually when inside the loop, chain is not empty, it's only outside of > it that it seems to be freed. Yes, perhaps because the certificate object is still in scope. What happens if you load all the certificates into a list in the loop, and build the chain from the list outside the loop, then the array still references the certificates. If we get too deep into Python, we'll be too far off topic, but for now, we're still vaguely talking about certificate management... -- Viktor. From fuckspam at wheres5.com Tue May 22 20:23:00 2018 From: fuckspam at wheres5.com (Hoggins!) Date: Tue, 22 May 2018 20:23:00 +0200 Subject: tlsa binary fails with certificate error In-Reply-To: <9A23DEEB-26E4-4FFC-A283-48074C16AA19@dukhovni.org> References: <57cff8d9-7a6b-5b8b-fe26-90c9d46a5605@wheres5.com> <4cd9ca1b-c862-fd1e-023f-008b9e19e9e8@wheres5.com> <47BF2857-0D63-4F93-B81B-480A28B31C59@dukhovni.org> <1545d4ff-f718-9d55-c6cb-94c935011eb1@wheres5.com> <9A23DEEB-26E4-4FFC-A283-48074C16AA19@dukhovni.org> Message-ID: <91665a38-0856-ed83-3ad2-87be6aceb9cf@wheres5.com> Le 22/05/2018 ? 16:49, Viktor Dukhovni a ?crit?: > >> On May 22, 2018, at 10:39 AM, Hoggins! wrote: >> >> Hello Viktor, >> >> I have published the correct TLSA records (generated with my "old" >> system) this morning, they are fixed for now. > Yes, I see that too. I've removed your domains from: > > https://github.com/danefail/list Thank you > >> Le 22/05/2018 ? 16:11, Viktor Dukhovni a ?crit : >>>> On May 22, 2018, at 5:05 AM, Hoggins! wrote: >>>> >>> I think I see the bug: >>> >>>> -- non working system : Fedora 28, python2-libs-2.7.15-1.fc28.x86_64 >>>> >>>> >>>> while True: >>>> cptr = m2.x509_read_pem(bio._ptr()) >>>> if not cptr: >>>> break >>>> chain.append(X509.X509(cptr, _pyfree=1)) >>> You're telling Python it owns the certificate object reference >>> and should free it when no longer needed. Then add the certificate >>> to the chain, but this call may not bump the certificate reference >>> count. >>> >>>> print chain >>> Here you print the chain. And the certificate itself goes out of >>> scope and is freed, the chain no longer holds a valid reference. >> Actually when inside the loop, chain is not empty, it's only outside of >> it that it seems to be freed. > Yes, perhaps because the certificate object is still in scope. What > happens if you load all the certificates into a list in the loop, > and build the chain from the list outside the loop, then the array > still references the certificates. > > If we get too deep into Python, we'll be too far off topic, but for > now, we're still vaguely talking about certificate management... > Anyway, I raised an issue on their GitHub, the maintainers should be able to have a look : https://github.com/letoams/hash-slinger/issues/20 ??? Hoggins! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From ietf-dane at dukhovni.org Thu May 31 23:44:15 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 31 May 2018 21:44:15 +0000 Subject: Update on stats 2018-05 Message-ID: <20180531214414.GX29327@mournblade.imrryr.org> Credits: Thanks to a substantial contribution of names of signed domains by Paul Vixie of Farsight Security, and smaller significant contribution by domains-index.com, the scope of the survey is substantially expanded from ~6.0 million to ~7.9 million domains. Unsurprisingly, the numbers for the major hosting providers are substantially larger than in April. Aside from the increase in the number of tested domains a new hosting provider "active24.com" (aka active24.cz) has enabled inbound and outbound DANE for their hosted domains. Thank you "active24.com" for improving the security of Internet email infrastructure. Summary: The DANE domain count is now 289,550. The number DNSSEC domains in the survey stands at 7,878,881, thus DANE TLSA is deployed on 3.67% of domains with DNSSEC. As of today I count 289,550 domains with correct SMTP DANE TLSA records at every primary MX host that accepts connections[1]. As expected the bulk of the DANE domains are hosted by the DNS/email hosting providers who've enabled DANE support in bulk for the domains they host. It is starting to get crowded at the top of the list, so I'm now listing the top 15 MX host providers by domain count: 100271 transip.nl 95922 domeneshop.no 33299 active24.com 23389 udmedia.de 9655 bhosted.nl 2281 nederhost.nl 1547 yourdomainprovider.net 1032 hi7.de 955 xcellerate.nl 927 surfmailfilter.nl 634 core-networks.de 629 omc-mail.com 508 mailbox.org 495 secure-gw.de 433 systemec.nl The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.nl/.cz/.de. Speaking of countries, the IPv4 GeoIP distribution of DANE-enabled MX hosts shows the below top 10 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented): 1402 DE, Germany 870 US, United States 508 NL, Netherlands 344 FR, France 166 GB, United Kingdom 121 CZ, Czech Republic 81 CA, Canada 65 SE, Sweden 59 CH, Switzerland 51 SG, Singapore IPv6 is still comparatively rare for MX hosts, and the top 10 countries by DANE MX host IPv6 GeoIP are (same top 6). 754 DE, Germany 431 US, United States 280 NL, Netherlands 187 FR, France 88 GB, United Kingdom 67 CZ, Czech Republic 36 SE, Sweden 24 SG, Singapore 23 CH, Switzerland 14 SI, Slovenia There are 3331 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. The number of published MX host TLSA RRsets found is 4785. These cover 5103 distinct MX hosts (some MX hosts share the same TLSA records through CNAMEs). The number of domains that at some point were listed in Gmail's email transparency report is 152 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 82 are in recent reports: gmx.at gmx.de overheid.nl travelbirdbelgique.be jpberlin.de pathe.nl nic.br lrz.de politie.nl registro.br mail.de truetickets.nl gmx.ch posteo.de uvt.nl open.ch ruhr-uni-bochum.de xs4all.nl anubisnetworks.com tum.de domeneshop.no gmx.com uni-erlangen.de handelsbanken.no mail.com unitybox.de webcruitermail.no solvinity.com unitymedia.de aegee.org trashmail.com web.de debian.org xfinity.com egmontpublishing.dk freebsd.org xfinityhomesecurity.com netic.dk gentoo.org xfinitymobile.com tilburguniversity.edu ietf.org active24.cz insee.fr isc.org clubcard.cz octopuce.fr netbsd.org cuni.cz comcast.net openssl.org cvc.cz dd24.net samba.org itesco.cz dns-oarc.net torproject.org klubpevnehozdravi.cz gmx.net asf.com.pt localssrcapp.cz hr-manager.net handelsbanken.se nic.cz mpssec.net iis.se smtp.cz t-2.net minmyndighetspost.se bayern.de xs4all.net skatteverket.se bund.de bhosted.nl t-2.si elster.de bit.nl govtrack.us fau.de boozyshop.nl freenet.de ouderportaal.nl Of the ~289000 domains, 1466 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 220. Some of these have additional MX hosts that don't have broken TLSA records, so mail can still arrive via the remaining MX hosts. A partial list is available at: https://github.com/danefail/list To avoid getting listed, please make sure to monitor the validity of your own TLSA records, and implement a reliable key rotation procedure. See: https://dane.sys4.de/common_mistakes http://imrryr.org/~viktor/ICANN61-viktor.pdf http://imrryr.org/~viktor/icann61-viktor.mp3 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 All the new blood in the survey has uncovered some previously unseen DNSSEC denial of existence breakage. After eliminating parked domains that do not accept email of any kind, the number of "real" email domains with bad DNSSEC support stands at 1171. The top 20 name server operators with problem domains are: 793 webspacecontrol.com / dotroll.com 52 mijnhostingpartner.nl 49 dotserv.com 22 sylconia.net 16 firstfind.nl 13 psb1.org 11 nazwa.pl 11 blauwblaatje.nl 10 metaregistrar.nl 8 zeptor.nl 8 tse.jus.br 8 dnscluster.nl 8 active24.cz 7 ignum.com 6 vultr.com 6 tiscomhosting.nl 6 host-redirect.com 6 glbns.com 6 domdom.hu 6 1cocomo.com The domains all whose nameservers have broken denial of existsnce that also appear in historical Google reports are: tre-ce.jus.br tre-sc.jus.br tre-rj.jus.br tre-sp.jus.br tse.jus.br -- Viktor. [1] Some domains deliberately include MX hosts that are always down, presumably as a hurdle to botnet SMTP code that gives up where real MTAs might persist. I am not a fan of this type of defence (it can also impose undue latency on legitimate email). However, provided the dead hosts still have TLSA records, (which don't need to match anything, just need to exist and be well-formed) there's no loss of security.