From ietf-dane at dukhovni.org Wed Apr 1 08:42:59 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 1 Apr 2020 02:42:59 -0400 Subject: Update on stats 2020-03 Message-ID: <20200401064259.GJ11496@straasha.imrryr.org> Summary: The DANE domain count is now 1,877,704. The number of domains that return DNSSEC-validated replies in response to MX queries is 10,922,412. Thus DANE TLSA is deployed on ~17.19% of domains with DNSSEC. Credits: The coverage of DNSSEC domains continues to improve with ongoing data support from Paul Vixie of Farsight Security. Credits also due to ICANN for gTLD data via CZDS, and to the TLD registries for .CH, .COM, .DK, .FR, .INFO, .IS, .LI, .NL, .NU, .ORG and .SE. More data sources of ccTLD signed delegations welcome. As of today I count 1,877,704 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 for the customer domains they host. The top 20 MX host providers by domain count are below. 1035802 one.com 136509 transip.nl 100753 domeneshop.no 88719 loopia.se 71404 infomaniak.ch 38325 active24.com 31059 vevida.com 30605 antagonist.nl 27536 webreus.nl 26933 web4u.cz 26278 zxcs.nl 24969 udmedia.de 17444 bhosted.nl 15192 flexfilter.nl 13854 onebit.cz 9816 protonmail.ch 5810 netzone.ch 5631 previder.nl 5477 soverin.net 4872 zonemx.eu The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.cz/.de/.eu/.be. Speaking of countries, the IPv4 GeoIP distribution of DANE-enabled MX hosts shows the below top 20 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented). 6347 TOTAL 2111 DE, Germany 1273 US, United States 919 NL, Netherlands 540 FR, France 261 GB, United Kingdom 215 CZ, Czechia 154 CA, Canada 87 CH, Switzerland 82 SG, Singapore 79 SE, Sweden 71 DK, Denmark 47 IE, Ireland 45 AU, Australia 41 AT, Austria 32 JP, Japan 28 IN, India 28 BR, Brazil 27 PL, Poland 25 RU, Russia 24 FI, Finland IPv6 is less common than IPv4 for MX hosts, and the top 20 countries by DANE MX host IPv6 GeoIP are: 3247 TOTAL 1324 DE, Germany 559 US, United States 467 NL, Netherlands 270 FR, France 124 CZ, Czechia 99 GB, United Kingdom 39 SE, Sweden 39 CH, Switzerland 39 CA, Canada 35 SG, Singapore 25 RU, Russia 24 AT, Austria 20 IE, Ireland 16 ID, Indonesia 16 DK, Denmark 15 AU, Australia 14 NO, Norway 14 JP, Japan 11 FI, Finland 11 BR, Brazil There are 5361 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 organizations deploying DANE SMTP. The number of published MX host TLSA RRsets found is 8115. These cover 9040 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 334 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 160 are in recent (last 90 days of) reports: univie.ac.at lrz.de hierinloggen.nl gmx.at mail.de intermax.nl nic.br mailserver4.de kingsquare.nl registro.br mensa.de mailplus.nl gmx.ch posteo.de minbzk.nl hostpoint.ch ruhr-uni-bochum.de mindef.nl infomaniak.ch tum.de mm1.nl open.ch uni-erlangen.de ouderportaal.nl protonmail.ch unitybox.de overheid.nl anubisnetworks.com unitymedia.de pathe.nl clubedominante.com web.de politie.nl comeseetv.com westlotto.de previder.nl fmc-na.com dk-hostmaster.dk rijksoverheid.nl frenchtogether.com egmontpublishing.dk rotterdam.nl gmx.com netic.dk ru.nl habr.com star.dk rvo.nl hotelsinduitsland.com stil.dk schoudercom.nl infomaniak.com uni-c.dk schuurman-schoenen.nl ingthink.com tilburguniversity.edu ssonet.nl kpn.com emta.ee truetickets.nl leszexpertsfle.com lugeja.ee uvt.nl mail.com rmit.ee xs4all.nl mammoetmail.com rediris.es zorgmail.nl one.com uv.es domeneshop.no primexbt.com litebit.eu handelsbanken.no protonmail.com web200.eu uib.no solvinity.com zone.eu webcruitermail.no t-2.com ac-strasbourg.fr atelkamera.nu telfort.com compagnie-des-sens.fr goget.nu thalesgroup.com octopuce.fr aegee.org trashmail.com web200.hu debian.org xfinity.com comcast.net freebsd.org xfinityhomesecurity.com dns-oarc.net gentoo.org xfinitymobile.com gmx.net ietf.org active24.cz habramail.net isc.org atlas.cz hr-manager.net mailbox.org centrum.cz inexio.net netbsd.org cuni.cz mpssec.net openssl.org itesco.cz procurios.net ozlabs.org klubpevnehozdravi.cz riseup.net samba.org krypton.cz t-2.net slackbuilds.org onebit.cz transip.net torproject.org optimail.cz xs4all.net whatpulse.org smtp.cz xworks.net asf.com.pt virusfree.cz belastingdienst.nl boplatssyd-automail.se volny.cz bhosted.nl handelsbanken.se bayern.de bluerail.nl loopia.se bund.de boozyshop.nl minmyndighetspost.se elster.de corpoflow.nl personligalmanacka.se fau.de dictu.nl skatteverket.se freenet.de digid.nl theletter.se gmx.de ezorg.nl govtrack.us jpberlin.de gerryweber.nl ru.ac.za kabelmail.de Of the ~1.88 million domains, 4504 have "partial" TLSA records, that cover only a subset of the (secondary) 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 465. Some of these have additional MX hosts that don't have broken TLSA records, so mail can still arrive via the remaining MX hosts. To avoid email outages, 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 https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17 https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources 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, the number of "real" email domains with bad DNSSEC support stands at 2050. The top 13 name server operators with problem domains are: 616 mijnhostingpartner.nl (fix expected any day now, but may be delayed) 559 registrar-servers.com (a.k.a. Neustar, continuing to grow slowly) 71 ebola.cz 70 movenext.nl 47 metaregistrar.nl 44 axc.nl 43 cdmon.net 37 hyp.net 34 flevohost.nl 30 tiscomhosting.nl 28 hostnet.nl 22 infracom.nl 18 is.nl If anyone has good contacts at some of these providers, please encourage them to remediate not only the broken domains (I can send them a list), but also the root cause that makes the breakage possible. Eleven of the domains all whose nameservers have broken denial of existence appear in the last 120 days of Google transparency reports: coren-sp.gov.br trt01.gov.br trtrio.gov.br trt1.jus.br trtrj.jus.br flytoyourheart.com topdecorationworld.com bncr.fi.cr mobily.com.sa sauditelecom.com.sa threadteaching.co.uk -- 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 Apr 5 15:34:16 2020 From: fuckspam at wheres5.com (Hoggins!) Date: Sun, 5 Apr 2020 15:34:16 +0200 Subject: Deprecating DNSSEC algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1) In-Reply-To: <20200110011942.GJ73491@straasha.imrryr.org> References: <20200110011942.GJ73491@straasha.imrryr.org> Message-ID: Le 10/01/2020 ? 02:19, Viktor Dukhovni a ?crit?: > If/when you do decide to switch algorithms, please perform the migration > with care. Algorithm rollovers can be tricky. Hello, Anyone using rollerd? I'd like to upgrade my algorithms and let rollerd do the whole rollover job for me, just by specifying that I'd like a specific alg to be used on the next shift, but I'm not sure how to do this. Thanks! -------------- 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 Apr 5 21:03:04 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 5 Apr 2020 15:03:04 -0400 Subject: Deprecating DNSSEC algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1) In-Reply-To: References: <20200110011942.GJ73491@straasha.imrryr.org> Message-ID: <20200405190304.GW41308@straasha.imrryr.org> On Sun, Apr 05, 2020 at 03:34:16PM +0200, Hoggins! wrote: > Le 10/01/2020 ? 02:19, Viktor Dukhovni a ?crit?: > > If/when you do decide to switch algorithms, please perform the migration > > with care. Algorithm rollovers can be tricky. > > Anyone using rollerd? I'd like to upgrade my algorithms and let rollerd > do the whole rollover job for me, just by specifying that I'd like a > specific alg to be used on the next shift, but I'm not sure how to do this. I have never heard of rollerd, but you might do better on a DNS list, rather than the dane-users list. Perhaps someone on the dns-operations list can help. https://lists.dns-oarc.net/mailman/listinfo/dns-operations -- Viktor. From jaap at NLnetLabs.nl Sun Apr 5 21:38:25 2020 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Sun, 05 Apr 2020 21:38:25 +0200 Subject: Deprecating DNSSEC algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1) In-Reply-To: <20200405190304.GW41308@straasha.imrryr.org> References: <20200110011942.GJ73491@straasha.imrryr.org> <20200405190304.GW41308@straasha.imrryr.org> Message-ID: <202004051938.035JcPs8025494@bela.nlnetlabs.nl> Viktor Dukhovni writes: > On Sun, Apr 05, 2020 at 03:34:16PM +0200, Hoggins! wrote: > > > Le 10/01/2020 ? 02:19, Viktor Dukhovni a ?crit?: > > > If/when you do decide to switch algorithms, please perform the migration > > > with care. Algorithm rollovers can be tricky. > > > > Anyone using rollerd? I'd like to upgrade my algorithms and let rollerd > > do the whole rollover job for me, just by specifying that I'd like a > > specific alg to be used on the next shift, but I'm not sure how to do this. > > I have never heard of rollerd, but you might do better on a DNS list, > rather than the dane-users list. Perhaps someone on the dns-operations > list can help. It is ancient and from the time before bind had key maintenance buikd in. And I don't think it will do an alogorithm rollover. See the man page (as in https://linux.die.net/man/1/rollerd). jaap From fuckspam at wheres5.com Mon Apr 6 10:45:43 2020 From: fuckspam at wheres5.com (Hoggins!) Date: Mon, 6 Apr 2020 10:45:43 +0200 Subject: Deprecating DNSSEC algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1) In-Reply-To: <20200405190304.GW41308@straasha.imrryr.org> References: <20200110011942.GJ73491@straasha.imrryr.org> <20200405190304.GW41308@straasha.imrryr.org> Message-ID: Le 05/04/2020 ? 21:03, Viktor Dukhovni a ?crit?: > I have never heard of rollerd, but you might do better on a DNS list, > rather than the dane-users list. Perhaps someone on the dns-operations > list can help. > > https://lists.dns-oarc.net/mailman/listinfo/dns-operations Thanks Viktor! Agreed this ML is probably not made for that. I'll look on that side of course, but even if it's off-topic, I'm open for suggestions on what tools you folks use for automated keys rollover. 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 Mon Apr 6 10:50:16 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 6 Apr 2020 04:50:16 -0400 Subject: Deprecating DNSSEC algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1) In-Reply-To: References: <20200110011942.GJ73491@straasha.imrryr.org> <20200405190304.GW41308@straasha.imrryr.org> Message-ID: <96C55E7D-44CE-4F46-9A88-6EF6A33DC6AE@dukhovni.org> > On Apr 6, 2020, at 4:45 AM, Hoggins! wrote: > > Agreed this ML is probably not made for that. I'll look on that side of > course, but even if it's off-topic, I'm open for suggestions on what > tools you folks use for automated keys rollover. I've not looked too closely yet, but BIND 9.16 automates many aspects of DNS key management, beyond the automatic zone signing available in earlier versions. Take a close look at BIND 9.16 documentation, try it out, and share your impressions... -- Viktor. From p at sys4.de Mon Apr 6 22:49:35 2020 From: p at sys4.de (Patrick Ben Koetter) Date: Mon, 6 Apr 2020 22:49:35 +0200 Subject: ANN: Support of DANE and DNSSEC in Office 365 Exchange Online Message-ID: <56330296-8ac9-026f-9ca2-045401bcbc95@sys4.de> All, I'm extremely pleased to post that Microsoft has announced today they will support DANE and DNSSEC in Office 365 Exchange Online. Their first step will be to support outbound DANE by end of 2020 and they plan to add inbound support for DANE by end of 2021. Please note that they will also implement support for TLSRPT , which is a good thing[tm] if you run strict TLS policies for your email platform. Well done, Microsoft! It's great to see a big player step forward, adopt DANE and make email more secure. p at rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schlei?heimer Stra?e 26/MG,80333 M?nchen Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4789 bytes Desc: S/MIME Cryptographic Signature URL: From bjorn at mork.no Tue Apr 7 17:15:48 2020 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 07 Apr 2020 17:15:48 +0200 Subject: ANN: Support of DANE and DNSSEC in Office 365 Exchange Online In-Reply-To: <56330296-8ac9-026f-9ca2-045401bcbc95@sys4.de> (Patrick Ben Koetter's message of "Mon, 6 Apr 2020 22:49:35 +0200") References: <56330296-8ac9-026f-9ca2-045401bcbc95@sys4.de> Message-ID: <87y2r7qqcb.fsf@miraculix.mork.no> Patrick Ben Koetter

writes: > Their first step will be to support outbound DANE by end of 2020 and > they plan to add inbound support for DANE by end of 2021. I believe the very first step will have to be adding EDNS support: https://ednscomp.isc.org/ednscomp/298e5889d8 No DNSSEC without EDNS. And no DANE without DNSSEC. Bj?rn From ietf-dane at dukhovni.org Tue Apr 7 20:51:15 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 7 Apr 2020 14:51:15 -0400 Subject: ANN: Support of DANE and DNSSEC in Office 365 Exchange Online In-Reply-To: <87y2r7qqcb.fsf@miraculix.mork.no> References: <56330296-8ac9-026f-9ca2-045401bcbc95@sys4.de> <87y2r7qqcb.fsf@miraculix.mork.no> Message-ID: <20200407185115.GD41308@straasha.imrryr.org> On Tue, Apr 07, 2020 at 05:15:48PM +0200, Bj?rn Mork wrote: > > Their first step will be to support outbound DANE by end of 2020 and > > they plan to add inbound support for DANE by end of 2021. > > I believe the very first step will have to be adding EDNS support: > https://ednscomp.isc.org/ednscomp/298e5889d8 > > No DNSSEC without EDNS. And no DANE without DNSSEC. Well, one can still do *outbound* DANE, without any support for DNSSEC or even EDNS for one's own domain, it suffices for the domains that are secured by DANE to have EDNS + DNSSEC + TLSA RRs for all their MX hosts. That said, I'm pleased to see that the link you posted shows that only one of the four tested nameservers for protection.outlook.com does not support EDNS, the other three are solid evidence that they can soon get there. That still leaves a different correctness problem that affects all the servers (there are at least three more nameservers IP addresses associated with the nameservers in question): @104.47.15.17 _25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA ? ; NotImp @104.47.67.17 _25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA ? ; NotImp @104.47.68.17 _25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA ? ; NotImp @104.47.69.17 _25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA ? ; NotImp @104.47.72.81 _25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA ? ; NotImp @104.47.118.145 _25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA ? ; NotImp @104.47.118.177 _25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA ? ; NotImp The correct response is "NXDomain" not "NotImp": @104.47.15.17 _25._tcp.nist-gov.mail.protection.outlook.com. IN A ? ; NXDomain @104.47.67.17 _25._tcp.nist-gov.mail.protection.outlook.com. IN A ? ; NXDomain @104.47.68.17 _25._tcp.nist-gov.mail.protection.outlook.com. IN A ? ; NXDomain @104.47.69.17 _25._tcp.nist-gov.mail.protection.outlook.com. IN A ? ; NXDomain @104.47.72.81 _25._tcp.nist-gov.mail.protection.outlook.com. IN A ? ; NXDomain @104.47.118.145 _25._tcp.nist-gov.mail.protection.outlook.com. IN A ? ; NXDomain @104.47.118.177 _25._tcp.nist-gov.mail.protection.outlook.com. IN A ? ; NXDomain -- Viktor. From ietf-dane at dukhovni.org Wed Apr 15 08:39:07 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 15 Apr 2020 02:39:07 -0400 Subject: Upcoming Glibc changes and DANE support in Postfix, Exim, and perhaps other MTAs Message-ID: <20200415063907.GO41308@straasha.imrryr.org> On Tue, Apr 14, 2020 at 05:59:51PM -0400, Viktor Dukhovni wrote: > but if that is incompatible with other stub resolver libraries on the > same machine, you may need a private musl-specific configuration file. > > My money is on this being unnecessary. I'll let [you] know what I find > from dns-operations, and if possible perhaps a RIPE ATLAS probe, > assuming they support enabling AD=1. Apparently sufficiently recent glibc supports soliciting and censoring the AD-bit. https://gnutoolchain-gerrit.osci.io/r/c/glibc/+/461/3/NEWS * The DNS stub resolver will optionally send the AD (authenticated data) bit in queries if the trust-ad option is set via the options directive in /etc/resolv.conf (or if RES_TRUSTAD is set in _res.options). In this mode, the AD bit, as provided by the name server, is available to applications which call res_search and related functions. In the default mode, the AD bit is not set in queries, and it is automatically cleared in responses, indicating a lack of DNSSEC validation. (Therefore, the name servers and the network path to them are treated as untrusted.) I read this to mean that the new "trust-ad" option, if set, causes the glibc stub resolver to set AD=1 in queries, but otherwise, causes it to strip the AD bit from replies. I don't yet have access to systems with this recent a glibc to confirm the above, but this is likely relevant to Postfix and Exim administrators who enable DANE. You may need to explicitly add the "trust-ad" option to your /etc/resolv.conf, while of course also making sure that all the listed nameservers are local (loopback interface). -- Viktor.