From ietf-dane at dukhovni.org Wed May 4 21:27:19 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 4 May 2016 19:27:19 +0000 Subject: Update on stats Message-ID: <20160504192719.GD3300@mournblade.imrryr.org> I've gained access to the full zone files for .com/.net and a few of the newer gTLDs. This makes it possible to do a more comprehensive survey of DANE SMTP support. The overall DANE domain count is now ~29800, but of course this is not a dramatic rise in adoption, rather an increase in the breadth of the survey. 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 five are: 16650 transip.nl 6020 udmedia.de 1110 nederhost.net 663 ec-elements.com 180 core-networks.de 24623 TOTAL 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 1850 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. Of the 29800 domains, 336 have "partial" TLSA records, that cover only a subset of the MX hosts, while this protects traffic to some of the MX hosts, the domain is 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 at 50. The number of domains with bad DNSSEC support is 262. The top 10 DNS providers (by broken domain count) are: 41 isphuset.no 36 tse.jus.br 22 axc.nl 21 active24.cz 20 registrar-servers.com 15 forpsi.net 11 ovh.net 11 cas-com.net 11 bestregistrar.com 10 shockmedia.nl Forpsi have indicated they are working on a fix. Progress at isphuset.no (ulimately fsdata.se) is still stalled. If someone has working technical contacts at any of the others, please drop me a note. The number of domains that at some point were listed in Gmail's transparency report is 57 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these 32 are in the most recent report: gmx.at conjur.com.br registro.br gmx.ch gmx.com mail.com bund.de gmx.de jpberlin.de kabelmail.de lrz.de mail.de posteo.de ruhr-uni-bochum.de tum.de web.de octopuce.fr comcast.net dd24.net gmx.net t-2.net xs4all.net xworks.net xs4all.nl debian.org freebsd.org gentoo.org ietf.org netbsd.org openssl.org samba.org torproject.org The .br TLD still includes too large a fraction (10/50) of domains with incorrect TLSA RRs. This is a result of DNS hosting by registro.br, where TLSA records are easy to initially publish, but difficult to keep up to date. If a registrar hosts the DNS, but does not operate the SMTP server, TLSA record support may do more harm than good unless an easy to use API is made available to update the TLSA records (interactive Web UIs don't qualify). -- Viktor. From cs at sys4.de Thu May 19 15:36:17 2016 From: cs at sys4.de (Carsten Strotmann (sys4)) Date: Thu, 19 May 2016 15:36:17 +0200 Subject: Issues delivering mail from GMX to my postfix Message-ID: Hi, I've got a report from a user that tries to send an mail from GMX to my private mail account. The mail-account is secured by DANE/TLSA and running on Postfix. "dane.sys4.de" does not report any issues, but GMX refuses to deliver mail with this message: ----------------------------schnipp---------------------------- This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: cas at strotmann.de: remote MX does not support STARTTLS ----------------------------schnipp---------------------------- Has anyone seen a similar issue? Any ideas how to troubleshoot? Best regards Carsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From patrickdk at patrickdk.com Thu May 19 16:37:15 2016 From: patrickdk at patrickdk.com (Patrick Domack) Date: Thu, 19 May 2016 10:37:15 -0400 Subject: Issues delivering mail from GMX to my postfix In-Reply-To: Message-ID: <20160519103715.Horde.0sIq1PgO8ebIr7RlbeVFuN0@mail.patrickdk.com> Looks like two different issues. The certificate name on smtp3.strotmann.de doesn't match, it is mail.tidelock.de instead. When using smtp2.strotmann.de, the TLS/DANE part works fine, but after this, and you attempt to send an email, it fails. posttls-finger: Verified TLS connection established to smtp2.strotmann.de[5.45.109.212]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) posttls-finger: > EHLO mx3.grsi.com posttls-finger: < 500 5.5.1 Command unrecognized posttls-finger: EHLO rejected: 500 5.5.1 Command unrecognized posttls-finger: > QUIT I am not sure what is talking here, but it's not postfix and it's not allowing the ehlo to be processed. Quoting "Carsten Strotmann (sys4)" : > Hi, > > I've got a report from a user that tries to send an mail from GMX to my > private mail account. > > The mail-account is secured by DANE/TLSA and running on Postfix. > "dane.sys4.de" does not report any issues, but GMX refuses to deliver > mail with this message: > > ----------------------------schnipp---------------------------- > This message was created automatically by mail delivery software. > > A message that you sent could not be delivered to one or more of > its recipients. This is a permanent error. The following address(es) > failed: > > cas at strotmann.de: > remote MX does not support STARTTLS > ----------------------------schnipp---------------------------- > > Has anyone seen a similar issue? Any ideas how to troubleshoot? > > Best regards > > Carsten From cs at sys4.de Thu May 19 17:02:59 2016 From: cs at sys4.de (Carsten Strotmann (sys4)) Date: Thu, 19 May 2016 17:02:59 +0200 Subject: Issues delivering mail from GMX to my postfix In-Reply-To: <20160519103715.Horde.0sIq1PgO8ebIr7RlbeVFuN0@mail.patrickdk.com> References: <20160519103715.Horde.0sIq1PgO8ebIr7RlbeVFuN0@mail.patrickdk.com> Message-ID: <573DD5A3.4040505@sys4.de> Hello Patrick, Patrick Domack wrote: > Looks like two different issues. > > The certificate name on smtp3.strotmann.de doesn't match, it is > mail.tidelock.de instead. Yes, true, but that should not be an issue when using DANE-EE(3) From https://tools.ietf.org/html/rfc7671#section-5.1 > In particular, the binding of the server public key to its > name is based entirely on the TLSA record association. The server > MUST be considered authenticated even if none of the names in the > certificate match the client's reference identity for the server. > > When using smtp2.strotmann.de, the TLS/DANE part works fine, but after > this, and you attempt to send an email, it fails. > posttls-finger: Verified TLS connection established to > smtp2.strotmann.de[5.45.109.212]:25: TLSv1.2 with cipher > ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) > posttls-finger: > EHLO mx3.grsi.com > posttls-finger: < 500 5.5.1 Command unrecognized > posttls-finger: EHLO rejected: 500 5.5.1 Command unrecognized > posttls-finger: > QUIT > > I am not sure what is talking here, but it's not postfix and it's not > allowing the ehlo to be processed. > This is OpenBSDs "spamd" intercepting. I need to check why it is intercepting here, and not transparent piping towards the Postfix. Thanks for the pointers, I will check that. -- Carsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 883 bytes Desc: OpenPGP digital signature URL: From ietf-dane at dukhovni.org Thu May 19 18:04:19 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 19 May 2016 16:04:19 +0000 Subject: Issues delivering mail from GMX to my postfix In-Reply-To: <573DD5A3.4040505@sys4.de> References: <20160519103715.Horde.0sIq1PgO8ebIr7RlbeVFuN0@mail.patrickdk.com> <573DD5A3.4040505@sys4.de> Message-ID: <20160519160418.GY3300@mournblade.imrryr.org> On Thu, May 19, 2016 at 05:02:59PM +0200, Carsten Strotmann (sys4) wrote: > > posttls-finger: Verified TLS connection established to > > smtp2.strotmann.de[5.45.109.212]:25: TLSv1.2 with cipher > > ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) > > posttls-finger: > EHLO mx3.grsi.com > > posttls-finger: < 500 5.5.1 Command unrecognized > > posttls-finger: EHLO rejected: 500 5.5.1 Command unrecognized > > posttls-finger: > QUIT > > > > I am not sure what is talking here, but it's not postfix and it's not > > allowing the ehlo to be processed. > > > > This is OpenBSDs "spamd" intercepting. I need to check why it is > intercepting here, and not transparent piping towards the Postfix. > > Thanks for the pointers, I will check that. I was going to guess that spamd or similar is the most likely culprit, even before you said you're running it. https://dane.sys4.de/common_mistakes#8 It might be enabling TLS only for cached "known good" clients, but that is not compatible with DANE. -- Viktor. From cs at sys4.de Thu May 19 19:26:46 2016 From: cs at sys4.de (Carsten Strotmann (sys4)) Date: Thu, 19 May 2016 19:26:46 +0200 Subject: Issues delivering mail from GMX to my postfix In-Reply-To: <20160519160418.GY3300@mournblade.imrryr.org> References: <20160519103715.Horde.0sIq1PgO8ebIr7RlbeVFuN0@mail.patrickdk.com> <573DD5A3.4040505@sys4.de> <20160519160418.GY3300@mournblade.imrryr.org> Message-ID: Hello Viktor, On 05/19/16 18:04, Viktor Dukhovni wrote: > On Thu, May 19, 2016 at 05:02:59PM +0200, Carsten Strotmann (sys4) wrote: > >>> posttls-finger: Verified TLS connection established to >>> smtp2.strotmann.de[5.45.109.212]:25: TLSv1.2 with cipher >>> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) >>> posttls-finger: > EHLO mx3.grsi.com >>> posttls-finger: < 500 5.5.1 Command unrecognized >>> posttls-finger: EHLO rejected: 500 5.5.1 Command unrecognized >>> posttls-finger: > QUIT >>> >>> I am not sure what is talking here, but it's not postfix and it's not >>> allowing the ehlo to be processed. >>> >> >> This is OpenBSDs "spamd" intercepting. I need to check why it is >> intercepting here, and not transparent piping towards the Postfix. >> >> Thanks for the pointers, I will check that. > > I was going to guess that spamd or similar is the most likely > culprit, even before you said you're running it. > > https://dane.sys4.de/common_mistakes#8 > > It might be enabling TLS only for cached "known good" clients, but > that is not compatible with DANE. > this seems to be the issue, Although "spamd" in its latest version does support TLS, *my* installation has stopped to offer STARTTLS. I need to check why that is. It also might be this issue: I will try the patch and check again. My 2nd MX (smtp3.strotmann.de) is a plain postfix on Debian doing STARTTLS and having DANE TLSA. If the first MX does not offer STARTTLS, shouldn't a sender try the 2nd MX (TLSA authenticated) mail-destination in case the first fails because of missing STARTTLS? If scanned RFC 7672, but couldn't find this case mentioned. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From ml+dane-users at esmtp.org Thu May 19 19:43:37 2016 From: ml+dane-users at esmtp.org (ml+dane-users at esmtp.org) Date: Thu, 19 May 2016 10:43:37 -0700 Subject: Issues delivering mail from GMX to my postfix In-Reply-To: References: <20160519103715.Horde.0sIq1PgO8ebIr7RlbeVFuN0@mail.patrickdk.com> <573DD5A3.4040505@sys4.de> <20160519160418.GY3300@mournblade.imrryr.org> Message-ID: <20160519174337.GA25144@x2.esmtp.org> On Thu, May 19, 2016, Carsten Strotmann (sys4) wrote: > this seems to be the issue, Although "spamd" in its latest version does > support TLS, *my* installation has stopped to offer STARTTLS. I need to Really? read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 32 2 read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 32 2 read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 30 0 read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0001 - read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 6d m read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 61 a read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 69 i read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 6c l read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 2e . read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 73 s read from 0x1003ee420 [0x1003f1270] (4096 bytes => 73 (0x49)) 0000 - 74 72 6f 74 6d 61 6e 6e-2e 64 65 20 45 53 4d 54 trotmann.de ESMT 0010 - 50 20 73 70 61 6d 64 20-49 50 2d 62 61 73 65 64 P spamd IP-based 0020 - 20 53 50 41 4d 20 62 6c-6f 63 6b 65 72 3b 20 54 SPAM blocker; T 0030 - 68 75 20 4d 61 79 20 31-39 20 31 39 3a 33 38 3a hu May 19 19:38: 0040 - 33 36 20 32 30 31 36 0d-0a 36 2016.. write to 0x1003ee420 [0x1003f2280] (25 bytes => 25 (0x19)) 0000 - 45 48 4c 4f 20 6f 70 65-6e 73 73 6c 2e 63 6c 69 EHLO openssl.cli 0010 - 65 6e 74 2e 6e 65 74 0d-0a ent.net.. read from 0x1003ee420 [0x1003f1270] (4096 bytes => 14 (0xE)) 0000 - 32 35 30 20 53 54 41 52-54 54 4c 53 0d 0a 250 STARTTLS.. write to 0x1003ee420 [-0x80005eb0] (10 bytes => 10 (0xA)) 0000 - 53 54 41 52 54 54 4c 53-0d 0a STARTTLS.. read from 0x1003ee420 [0x1003e3730] (8192 bytes => 56 (0x38)) 0000 - 32 32 30 20 67 6c 61 64-20 79 6f 75 20 77 61 6e 220 glad you wan 0010 - 74 20 74 6f 20 62 75 72-6e 20 6d 6f 72 65 20 43 t to burn more C 0020 - 50 55 20 63 79 63 6c 65-73 20 6f 6e 20 79 6f 75 PU cycles on you 0030 - 72 20 73 70 61 6d 0d 0a- r spam.. SSL_connect:before/connect initialization ... Server certificate subject=/CN=mail.strotmann.de issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1 --- No client certificate CA names sent --- SSL handshake has read 3576 bytes and written 538 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2560 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 4DE94964346F99C2798593C6A16A37CC03CFBFEB1B12218A7D647D9CC5521666 Session-ID-ctx: Master-Key: 89C06D81DEA6438E523840D8854C07D4AD7D8CB5DADAE878F218E0E085BB3D483886E79D7CB336A4EEB78411C4E4CEAB Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 97 2f 4b 2b 96 1f 0c 6f-f9 7b fb b0 79 2c af 3e ./K+...o.{..y,.> 0010 - 61 9a 27 21 e7 0f 8f 33-8c 0b ab 37 09 34 ed c1 a.'!...3...7.4.. 0020 - e3 c2 f8 a7 bf 4c 41 e3-d4 2a f7 37 6f e7 28 fd .....LA..*.7o.(. 0030 - 50 b0 ab 69 a4 67 78 89-38 27 32 55 62 13 b9 5d P..i.gx.8'2Ub..] 0040 - 14 2e 4d ee 83 57 57 2c-45 23 91 b8 e4 a9 7e 89 ..M..WW,E#....~. 0050 - 8f bd 43 7d 67 9b e7 7a-96 bc d4 ae 21 0e 29 34 ..C}g..z....!.)4 0060 - 3f 42 92 76 25 00 9e 98-56 6d 90 16 70 50 d6 d9 ?B.v%...Vm..pP.. 0070 - ea 81 30 b4 e4 62 1e d0-eb 01 fb 1d b2 ed d0 48 ..0..b.........H 0080 - f1 d7 83 32 2d 16 3e c0-06 6f ed f5 21 e6 e4 ed ...2-.>..o..!... 0090 - 3d e8 29 ae 69 9e 4b 5f-31 1b 65 0d 89 69 e9 b5 =.).i.K_1.e..i.. 00a0 - 6d 8e ce ba 14 35 64 7b-4b cb b4 d3 4e f5 fb d8 m....5d{K...N... 00b0 - 26 e9 9c 7f f2 d3 dd d4-5c 2c 71 bb f3 36 46 3d &.......\,q..6F= Start Time: 1463679529 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- 250 STARTTLS EHLO o write to 0x1003ee420 [0x1003fad43] (37 bytes => 37 (0x25)) 0000 - 17 03 03 00 20 38 8b 1c-03 e7 00 4b 6e e0 f4 14 .... 8.....Kn... 0010 - 0b 62 7f 8e 04 c5 d0 f6-5e 53 92 25 9e 3d 5b 0c .b......^S.%.=[. 0020 - 44 6f 70 ad fe Dop.. read from 0x1003ee420 [0x1003f67e3] (5 bytes => 5 (0x5)) 0000 - 17 03 03 00 38 ....8 read from 0x1003ee420 [0x1003f67e8] (56 bytes => 56 (0x38)) 0000 - 00 00 00 00 00 00 00 01-23 3e ab e4 d8 d5 fb 4c ........#>.....L 0010 - 62 72 85 da 80 aa f2 c1-6c 02 ae 3f 08 de 1a 66 br......l..?...f 0020 - 71 d2 72 b7 e8 88 4d af-56 22 82 4d 07 95 71 88 q.r...M.V".M..q. 0030 - 47 af 04 df 0f ec 28 60- G.....(` 500 5.5.1 Command unrecognized quit Seems STARTTLS is offered and "kind of" working... but then EHLO fails. Maybe you should just use a real MTA... (or figure out why spamd behaves this way and fix it?) From ietf-dane at dukhovni.org Thu May 19 20:05:17 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 19 May 2016 18:05:17 +0000 Subject: Issues delivering mail from GMX to my postfix In-Reply-To: References: <20160519103715.Horde.0sIq1PgO8ebIr7RlbeVFuN0@mail.patrickdk.com> <573DD5A3.4040505@sys4.de> <20160519160418.GY3300@mournblade.imrryr.org> Message-ID: <20160519180517.GD3300@mournblade.imrryr.org> On Thu, May 19, 2016 at 07:26:46PM +0200, Carsten Strotmann (sys4) wrote: > My 2nd MX (smtp3.strotmann.de) is a plain postfix on Debian doing > STARTTLS and having DANE TLSA. If the first MX does not offer STARTTLS, > shouldn't a sender try the 2nd MX (TLSA authenticated) mail-destination > in case the first fails because of missing STARTTLS? It definitely should. DANE clients should not impose a single point of failure at the primary MX host. However, your primary MX host has both an IPv4 and an IPv6 address, and if GMX is using Postfix as their outbound, perhaps they've set http://www.postfix.org/postconf.5.html#smtp_mx_address_limit to 2? This would preclude ever connecting to your backup MX. Failure to complete TLS handshakes does not count against the http://www.postfix.org/postconf.5.html#smtp_mx_session_limit However, the above is a rather improbable wild guess, no idea why they don't try the backup. > I scanned RFC 7672, but couldn't find this case mentioned. Section 2.2: A "secure" TLSA RRset with at least one usable record: Any connection to the MTA MUST employ TLS encryption and MUST authenticate the SMTP server using the techniques discussed in the rest of this document. Failure to establish an authenticated TLS connection MUST result in falling back to the next SMTP server or delayed delivery. I think you know some the GMX staff in person. In which case, reach out to them, they may be able to look into what the problem looks like on their end. If you don't, drop me a note, and I'll forward the contact info I have. They should be interested in ironing out any implementation limitations on their end. -- Viktor. From cs at sys4.de Mon May 23 08:01:01 2016 From: cs at sys4.de (Carsten Strotmann) Date: Mon, 23 May 2016 08:01:01 +0200 Subject: Issues delivering mail from GMX to my postfix In-Reply-To: <20160519160418.GY3300@mournblade.imrryr.org> References: <20160519103715.Horde.0sIq1PgO8ebIr7RlbeVFuN0@mail.patrickdk.com> <573DD5A3.4040505@sys4.de> <20160519160418.GY3300@mournblade.imrryr.org> Message-ID: <20160523080101.22f9e6da.cs@sys4.de> Hello Viktor, Hello List-Participants, On Thu, 19 May 2016 16:04:19 +0000 Viktor Dukhovni wrote: > I was going to guess that spamd or similar is the most likely > culprit, even before you said you're running it. > > https://dane.sys4.de/common_mistakes#8 > > It might be enabling TLS only for cached "known good" clients, but > that is not compatible with DANE. I've found the issue, it was a configuration error on my behalf on the IPv4 side of "smtp2.strotmann.de" that causes STARTTLS to be denied (for all clients). The IPv6 side of the configuration was always working and most mail-sender preferred IPv6, that is the reason why the configuration issue was not seen immediatly. Lesson learned: monitoring needs to cover IPv4 and IPv6 separatly. The GMX people have contacted me and were very helpful in debugging this issue. This now seems to be fixed, mail from GMX is coming in again. Have a good week! Carsten -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From ietf-dane at dukhovni.org Wed May 25 10:45:17 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 May 2016 08:45:17 +0000 Subject: Update on stats In-Reply-To: <20160504192719.GD3300@mournblade.imrryr.org> References: <20160504192719.GD3300@mournblade.imrryr.org> Message-ID: <20160525084517.GG12310@mournblade.imrryr.org> On Wed, May 04, 2016 at 07:27:19PM +0000, Viktor Dukhovni wrote: > The overall DANE domain count is now ~29800, but of course this is > not a dramatic rise in adoption, rather an increase in the breadth > of the survey. This count is now at 30976, primarily as new domains are added by the top hosting providers. > 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 five are: > > 16650 transip.nl > 6020 udmedia.de > 1110 nederhost.net > 663 ec-elements.com > 180 core-networks.de > 24623 TOTAL The top 5 are now: 17537 transip.nl 6060 udmedia.de 1113 nederhost.net 683 ec-elements.com 225 core-networks.de 25618 TOTAL > The number of domains with incorrect TLSA records or failure to > advertise STARTTLS (even though TLSA records are published) stands > at 50. That count is now 60, the domains are below. If someone has better contacts than WHOIS for these, that'd be great. f2h.at hanisauland.at bebidaliberada.com.br giantit.com.br lojabrum.com.br prodnsbr.com.br simplesestudio.com.br sistemasranf.com.br solucoesglobais.com.br ticketmt.com.br twsolutions.net.br iress.co 2cv-club-des-ducs.com 4nettech.com aircargo-statistics.com barbarassecret.com dentalembezzlement.com gedankenausbruch.com kkeane.com kriegshysterie.com lastsip.com leatherfest.com nctechcenter.com prosperident.com talideon.com tntmonitoring.com bels.cz 101host.de 1post.de apachedemo.de badf00d.de dopesoft.de mcplayman.de mrkrabat.de thestoneage.de 22december.dk macnaughton.email chets.fr planissimo.fr tni-au.mil.id nonoserver.info chauvet.me rk-mail.me stereochro.me castleturing.net freeservices.net kuzenkova.net linlab.net rk-mail.net steelyard.nl wm.net.nz gazonk.org glux.org myhead.org rogaar.org itaskmanager.ovh kriegshysterie.ovh rk-mail.ovh skyneaker.ovh taskmanager.ovh > The number of domains with bad DNSSEC support is 262. That's now 214. > The top 10 DNS providers (by broken domain count) are: 34 isphuset.no 19 axc.nl 12 registrar-servers.com 11 cas-com.net 11 active24.cz 10 netcup.net 8 forpsi.net 5 pfsc.com 5 ovh.net 5 metaregistrar.nl The folks at netcup.net have just reached out, with a bit of luck that'll be resolved in the not too distant future. > Forpsi have indicated they are working on a fix. Progress at > isphuset.no (ulimately fsdata.se) is still stalled. If someone > has working technical contacts at any of the others, please drop > me a note. Still looking for contacts for the other hosting providers. > The number of domains that at some point were listed in Gmail's > transparency report is 57 (this is my ad-hoc criterion for a domain > being a large-enough actively used email domain). That's now 60. > Of these 32 are in the most recent report: That's now 33, with the addition of unitymedia.de. > The .br TLD still includes too large a fraction (10/50) of domains > with incorrect TLSA RRs. This is a result of DNS hosting by > registro.br, where TLSA records are easy to initially publish, but > difficult to keep up to date. They've acknowledged my request to drop support for TLSA RRs for the free hosted domains, where there's no easy way to keep the records current. Whether they'll take action on that is not yet clear. -- Viktor. From ietf-dane at dukhovni.org Wed May 25 20:52:23 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 May 2016 18:52:23 +0000 Subject: Update on stats In-Reply-To: <20160525084517.GG12310@mournblade.imrryr.org> References: <20160504192719.GD3300@mournblade.imrryr.org> <20160525084517.GG12310@mournblade.imrryr.org> Message-ID: <20160525185223.GH12310@mournblade.imrryr.org> On Wed, May 25, 2016 at 08:45:17AM +0000, Viktor Dukhovni wrote: > > The number of domains with bad DNSSEC support is 262. > > That's now 214. And now down to 204, because: > 10 netcup.net > > The folks at netcup.net have just reached out, with a bit of luck > that'll be resolved in the not too distant future. Problem fixed within a day of the report. It be great if other operators were equally responsive. -- Viktor.