From ietf-dane at dukhovni.org Sun Mar 1 10:17:01 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 1 Mar 2020 04:17:01 -0500 Subject: Update on stats 2020-02 Message-ID: <20200301091701.GU11496@straasha.imrryr.org> Summary: The DANE domain count is now 1,842,179. The number of domains that return DNSSEC-validated replies in response to MX queries is 10,837,476. Thus DANE TLSA is deployed on ~17.00% 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,842,179 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. 1039151 one.com 135237 transip.nl 100341 domeneshop.no 88535 loopia.se 68917 infomaniak.ch 37835 active24.com 31227 vevida.com 30345 antagonist.nl 26692 web4u.cz 24813 udmedia.de 22509 zxcs.nl 17374 bhosted.nl 15308 flexfilter.nl 13690 onebit.cz 9518 protonmail.ch 5814 netzone.ch 5575 previder.nl 5163 soverin.net 4756 mailplatform.eu 4321 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). 6251 TOTAL 2084 DE, Germany 1246 US, United States 896 NL, Netherlands 549 FR, France 256 GB, United Kingdom 201 CZ, Czechia 153 CA, Canada 85 CH, Switzerland 83 SG, Singapore 78 SE, Sweden 69 DK, Denmark 46 AT, Austria 44 IE, Ireland 43 JP, Japan 39 AU, Australia 31 BR, Brazil 27 RU, Russia 26 PL, Poland 25 IT, Italy 23 IN, India IPv6 is less common than IPv4 for MX hosts, and the top 20 countries by DANE MX host IPv6 GeoIP are: 3176 TOTAL 1311 DE, Germany 531 US, United States 453 NL, Netherlands 263 FR, France 112 CZ, Czechia 98 GB, United Kingdom 41 SE, Sweden 35 SG, Singapore 34 AT, Austria 33 CH, Switzerland 32 JP, Japan 32 CA, Canada 31 RU, Russia 17 IE, Ireland 16 DK, Denmark 14 SI, Slovenia 13 NO, Norway 13 AU, Australia 12 ID, Indonesia 12 BR, Brazil There are 5296 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 8054. These cover 8964 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 322 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 155 are in recent (last 90 days of) reports: univie.ac.at jpberlin.de minbzk.nl gmx.at kabelmail.de mindef.nl register.bg lrz.de mm1.nl nic.br mail.de ouderportaal.nl registro.br mailserver4.de overheid.nl buymyweedonline.ca posteo.de pathe.nl gmx.ch ruhr-uni-bochum.de photofacts.nl infomaniak.ch tum.de politie.nl open.ch uni-erlangen.de previder.nl protonmail.ch uni-muenchen.de rijksoverheid.nl anubisnetworks.com unitybox.de ru.nl clubedominante.com unitymedia.de rvo.nl fmc-na.com web.de schoudercom.nl gmx.com egmontpublishing.dk schuurman-schoenen.nl habr.com netic.dk ssonet.nl hotelsinduitsland.com star.dk truetickets.nl infomaniak.com tilburguniversity.edu uvt.nl ingthink.com emta.ee xs4all.nl kpn.com lugeja.ee zorgmail.nl leszexpertsfle.com rmit.ee domeneshop.no mail.com rediris.es handelsbanken.no mammoetmail.com uv.es uib.no one.com web200.eu webcruitermail.no primexbt.com zone.eu atelkamera.nu protonmail.com ac-strasbourg.fr goget.nu solvinity.com compagnie-des-sens.fr aegee.org t-2.com octopuce.fr debian.org telfort.com web200.hu freebsd.org trashmail.com comcast.net gentoo.org vitstore.com dns-oarc.net ietf.org xfinity.com gmx.net isc.org xfinityhomesecurity.com habramail.net lazarus-ide.org xfinitymobile.com hr-manager.net mailbox.org active24.cz inexio.net netbsd.org atlas.cz mpssec.net openssl.org centrum.cz procurios.net ozlabs.org cuni.cz riseup.net samba.org itesco.cz t-2.net slackbuilds.org klubpevnehozdravi.cz transip.net torproject.org krypton.cz vevida.net whatpulse.org onebit.cz xs4all.net asf.com.pt optimail.cz xworks.net moikrug.ru smtp.cz belastingdienst.nl boplatssyd-automail.se virusfree.cz bhosted.nl handelsbanken.se volny.cz bluerail.nl loopia.se web4u.cz boozyshop.nl minmyndighetspost.se bayern.de corpoflow.nl personligalmanacka.se bund.de dictu.nl skatteverket.se elster.de digid.nl theletter.se fau.de intermax.nl govtrack.us freenet.de jasperalblas.nl ru.ac.za gmx.de mailplus.nl Of the ~1.84 million domains, 4424 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 466. 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 1846. The top 13 name server operators with problem domains are: 482 registrar-servers.com (count still growing slowly) 348 mijnhostingpartner.nl (operator expects a fix "before long") 275 axc.nl (new this month :-( ) 82 egensajt.se 64 movenext.nl 56 ebola.cz 46 metaregistrar.nl 30 tiscomhosting.nl 27 hostnet.nl 23 infracom.nl 22 cdmon.net 20 sylconia.net 17 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. Nine (same as last month) of the domains all whose nameservers have broken denial of existence appear in the last 120 days of Google transparency reports: trt01.gov.br trtrio.gov.br trt1.jus.br trtrj.jus.br flytoyourheart.com topdecorationworld.com 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 peter.van.dijk at powerdns.com Fri Mar 6 17:33:42 2020 From: peter.van.dijk at powerdns.com (Peter van Dijk) Date: Fri, 06 Mar 2020 17:33:42 +0100 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: <9f7931be0ab512bfa1120a716059c26b8fb45174.camel@powerdns.com> On Thu, 2020-01-09 at 20:19 -0500, Viktor Dukhovni wrote: > If/when you do decide to switch algorithms, please perform the migration > with care. Algorithm rollovers can be tricky. The basic process is: > > 1. Publish and activate a ZSK for the new algorithm. Your zone > should now be double-signed, which each record having two > RRSIGs. Don't forget to bump the SOA. Your zone is now bogus. > The reason for all this is to maintain the followin invariants: > > A. Each algorithm mentioned in the parent zone DS RRset must > have a matching KSK in the zone's DNSKEY RRset. > > B. Each KSK algorithm appearing in the zone's DNSKEY RRset > must have a corresponding ZSK signature for each record > in the zone. You are missing: C. Each algorithm for which a DNSKEY exists, must sign all the records in the zone. Because of caching, step 1 potentially breaks this invariant. https://tools.ietf.org/html/rfc6781#section-4.1.4 explains this at length (with better wording than I used), and appears to get it right. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From ietf-dane at dukhovni.org Fri Mar 6 17:55:05 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 6 Mar 2020 11:55:05 -0500 Subject: Deprecating DNSSEC algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1) In-Reply-To: <9f7931be0ab512bfa1120a716059c26b8fb45174.camel@powerdns.com> References: <20200110011942.GJ73491@straasha.imrryr.org> <9f7931be0ab512bfa1120a716059c26b8fb45174.camel@powerdns.com> Message-ID: <20200306165505.GK7977@straasha.imrryr.org> On Fri, Mar 06, 2020 at 05:33:42PM +0100, Peter van Dijk wrote: > On Thu, 2020-01-09 at 20:19 -0500, Viktor Dukhovni wrote: > > If/when you do decide to switch algorithms, please perform the migration > > with care. Algorithm rollovers can be tricky. The basic process is: > > > > 1. Publish and activate a ZSK for the new algorithm. Your zone > > should now be double-signed, which each record having two > > RRSIGs. Don't forget to bump the SOA. > > Your zone is now bogus. No it is not. The zone is signed with two ZSKs, one for each algorithm. The idea is sign the zone *at the same time* as the ZSK is introduced, not add the ZSK and sign later. > > The reason for all this is to maintain the followin invariants: > > > > A. Each algorithm mentioned in the parent zone DS RRset must > > have a matching KSK in the zone's DNSKEY RRset. > > > > B. Each KSK algorithm appearing in the zone's DNSKEY RRset > > must have a corresponding ZSK signature for each record > > in the zone. > > You are missing: > > C. Each algorithm for which a DNSKEY exists, must sign all the records > in the zone. And the invariant holds, because it is signed with ZSKs for both algorithms. > Because of caching, step 1 potentially breaks this invariant. > > https://tools.ietf.org/html/rfc6781#section-4.1.4 explains this at > length (with better wording than I used), and appears to get it right. -- VIktor. From bjorn at mork.no Sat Mar 7 11:32:11 2020 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sat, 07 Mar 2020 11:32:11 +0100 Subject: Deprecating DNSSEC algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1) In-Reply-To: <20200306165505.GK7977@straasha.imrryr.org> (Viktor Dukhovni's message of "Fri, 6 Mar 2020 11:55:05 -0500") References: <20200110011942.GJ73491@straasha.imrryr.org> <9f7931be0ab512bfa1120a716059c26b8fb45174.camel@powerdns.com> <20200306165505.GK7977@straasha.imrryr.org> Message-ID: <87zhcso3pw.fsf@miraculix.mork.no> Viktor Dukhovni writes: > On Fri, Mar 06, 2020 at 05:33:42PM +0100, Peter van Dijk wrote: >> C. Each algorithm for which a DNSKEY exists, must sign all the records >> in the zone. > > And the invariant holds, because it is signed with ZSKs for both > algorithms. > >> Because of caching, step 1 potentially breaks this invariant. >> >> https://tools.ietf.org/html/rfc6781#section-4.1.4 explains this at >> length (with better wording than I used), and appears to get it right. You didn't really address Peter's concern. Any cached RRSIG with remaining TTL higher than a cached DNSKEY will be invalid after the cached DNSKEY expires if you add a new ZSK algorithm without first adding the signatures.. You need to add the signatures first, wait until old sigs are expired, and then add the new ZSK. Looking at an example: My local resolver is going to keep the www.ietf.org RRSIG cached for 589 seconds after the ietf.org DNSKEY expires. If ietf.org were to add a ZSK with a new algorithm now, then www.ietf.org will be considered invalid for those 589 seconds until the cache picks up the new signature: bjorn at miraculix:~$ dig dnskey ietf.org +dnssec +multiline; dig www.ietf.org +dnssec +multiline ; <<>> DiG 9.11.5-P4-5.1-Debian <<>> dnskey ietf.org +dnssec +multiline ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25914 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 00d41f1eaa6c1e2b0d935c335e637697980f4266912fe3c1 (good) ;; QUESTION SECTION: ;ietf.org. IN DNSKEY ;; ANSWER SECTION: ietf.org. 589 IN DNSKEY 257 3 5 ( AwEAAavjQ1H6pE8FV8LGP0wQBFVL0EM9BRfqxz9p/sZ+ 8AByqyFHLdZcHoOGF7CgB5OKYMvGOgysuYQloPlwbq7W s5WywbutbXyG24lMWy4jijlJUsaFrS5EvUu4ydmuRc/T GnEXnN1XQkO+waIT4cLtrmcWjoY8Oqud6lDaJdj1cKr2 nX1NrmMRowIu3DIVtGbQJmzpukpDVZaYMMAm8M5vz4U2 vRCVETLgDoQ7rhsiD127J8gVExjO8B0113jCajbFRcMt UtFTjH4z7jXP2ZzDcXsgpe4LYFuenFQAcRBRlE6oaykH R7rlPqqmw58nIELJUFoMcb/BdRLgbyTeurFlnxs= ) ; KSK; alg = RSASHA1 ; key id = 45586 ietf.org. 589 IN DNSKEY 256 3 5 ( AwEAAdDECajHaTjfSoNTY58WcBah1BxPKVIHBz4IfLjf qMvium4lgKtKZLe97DgJ5/NQrNEGGQmr6fKvUj67cfrZ UojZ2cGRizVhgkOqZ9scaTVXNuXLM5Tw7VWOVIceeXAu uH2mPIiEV6MhJYUsW6dvmNsJ4XwCgNgroAmXhoMEiWEj BB+wjYZQ5GtZHBFKVXACSWTiCtddHcueOeSVPi5WH94V lubhHfiytNPZLrObhUCHT6k0tNE6phLoHnXWU+6vpsYp z6GhMw/R9BFxW5PdPFIWBgoWk2/XFVRSKG9Lr61b2z1R 126xeUwvw46RVy3hanV3vNO7LM5HniqaYclBbhk= ) ; ZSK; alg = RSASHA1 ; key id = 40452 ietf.org. 589 IN RRSIG DNSKEY 5 2 1800 ( 20210127000407 20200127230611 40452 ietf.org. wiauz1dcDs1GctjHvWCw5Xxt61nTZhG7fjx5/+mC/uaL 3GKYwjS7cyBYl/YcXuufSAWFQLBy7BXFIkIxbXyKkCCo uKogFWhoEilYZhUu/GxEppCK1Y7hvokM0i9enBlu7UDQ GvJ9m9buJaKGtcKkiOAOTJB2djeyEexlgOpsQFst1TtM DX6C7pdCjeaqTbFQrzq0LIBjthLJEzMWO4jNTr7bNcpi 8+nFDWV1MogDDP9cm8H89vMf4bUfqSvkskq2ouLNGwJ+ 6gyDqUWu3KR8FvOhOWpq040/6ZWXMAduq5JDbt80oNdD 1xjwkhCQDI28fVj0v96MaQTWwR4Brj6p4Q== ) ietf.org. 589 IN RRSIG DNSKEY 5 2 1800 ( 20210127000433 20200127230611 45586 ietf.org. NRattAGqWXC55uwxwK+iCZhIj81/ljephfA+Hx57jEES N2tCI4ZCldvOOtCojtkKnFchSsNoEfkuYpJtoAENlKat jxBFYmAJJESqoV/X+jh5Y0j45787hF9TMc51//a6qjSl PA3QJLZ2kReVgBRsBDQ9MroWaAWYKnsZOGKIKyg6Rxha ADS/ATg/3kq2XZJuKRXHKx2sdCvqhMpuejgdqr/+SU2K LUdPWrtvLmWRAP73MRIsBy52/rqR4iKkXhRLa6hPkovn hikLibD6wijh53T0Oyqsj0mlpUEQSI6uV5b/9hp0TXpl QhYCiDSuH1cu5fe/pgLvRpxkIEzof58vow== ) ;; Query time: 28 msec ;; SERVER: 148.122.16.253#53(148.122.16.253) ;; WHEN: Sat Mar 07 11:25:27 CET 2020 ;; MSG SIZE rcvd: 1209 ; <<>> DiG 9.11.5-P4-5.1-Debian <<>> www.ietf.org +dnssec +multiline ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11102 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 4ff4c9a2b04e7362cc9958945e6376979d3ae21152d8ec4d (good) ;; QUESTION SECTION: ;www.ietf.org. IN A ;; ANSWER SECTION: www.ietf.org. 1175 IN CNAME www.ietf.org.cdn.cloudflare.net. www.ietf.org. 1175 IN RRSIG CNAME 5 3 1800 ( 20210127000323 20200127230611 40452 ietf.org. fX/FCVGya8pIk/2cMDWu3+iNKyWd0GLK4g6wtwp8v7rj p+nynpRm1jOanP20p36Dod4qj0IdoMGu3PN2756QZW7L zQ6nS+x7Re37Q52BP89ADXZ5J5tLlcaRl0MEyoj6/Cyv 6cW+GH8sK0PwYmE11mVzezI3ZrADWvTCmgNxEpxHxoF0 jlpJ0+JVt9gP2bbHWg0uF2yspTwspaoCSRcaO6KFKnkk QXI2PFhgk0w/Od4NXe86V64U1WtMGcqNyGOe0zcq4HPm iiW+lvZab6QuZJ8kq/A5HrDw66MzuRK5S2PJFjoF7lna 9OIru9JXT+FcHmozUpI9lwLJIwI5IRt11g== ) www.ietf.org.cdn.cloudflare.net. 300 IN A 104.20.0.85 www.ietf.org.cdn.cloudflare.net. 300 IN A 104.20.1.85 www.ietf.org.cdn.cloudflare.net. 300 IN RRSIG A 13 6 300 ( 20200308112527 20200306092527 34505 cloudflare.net. gEbu+OUEYzpr2m4Tsvukhpxyyy0ypEW1esxKg/q3qVQW nfeGk7PTcH2oqcplMI+d/9cMQPJW7v0m+/dHXq97FA== ) ;; Query time: 31 msec ;; SERVER: 148.122.16.253#53(148.122.16.253) ;; WHEN: Sat Mar 07 11:25:27 CET 2020 ;; MSG SIZE rcvd: 552 Bj?rn