From ietf-dane at dukhovni.org Sat Nov 11 09:53:52 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 11 Nov 2017 08:53:52 +0000 Subject: DANE stats update: all jsr-it.nl DNS issues resolved. In-Reply-To: <20171026063142.GD29327@mournblade.imrryr.org> References: <20171026063142.GD29327@mournblade.imrryr.org> Message-ID: <20171111085352.GF29327@mournblade.imrryr.org> On Thu, Oct 26, 2017 at 06:31:42AM +0000, Viktor Dukhovni wrote: > After eliminating parked domains that do not accept email of any > kind, The number of "real" email domains with bad DNSSEC support > stands at 175. (The accenture.com domains from the previous > report were all parked). The top 10 name server operators with > problem domains are: > > 63 jsr-it.nl > 17 firstfind.nl > 7 active24.cz > 5 tse.jus.br > 4 glbns.com > 3 cas-com.net > 2 tiscomhosting.nl > 2 sylconia.net > 2 psyclonecontacts.net > 2 ns01.nl All previously seen problem domains served by jsr-it.nl nameservers no longer exhibit any issues with TLSA record lookup. Thus the problem domain count is now down to 125, with the top 10 now: 22 firstfind.nl 7 active24.cz 5 tse.jus.br 4 glbns.com 3 metaregistrar.nl 3 cas-com.net 2 webhostingserver.nl 2 tiscomhosting.nl 2 sylconia.net 2 psyclonecontacts.net When firstfind.nl fix their nameserver bugs, (nameservers return NODATA, along with NSEC3 records that actually prove NXDOMAIN): http://dnsviz.net/d/_25._tcp.econo.nl/dnssec/ we'll have exhausted all the major concentrations of DNS problems, with the remaining issues being largely confined to individual domains, and not systemic at DNS hosting providers. I should note that the 7 problem domains at active24.cz are not systemic issues with their DNS software. Rather, some hosted domains have bad wildcard CNAME records (presumably misconfigured by the customer). For example: _25._tcp.greif-cz.cz. CNAME www.greif-cz.cz.greif-cz.cz. www.greif-cz.cz.greif-cz.cz. CNAME www.greif-cz.cz.greif-cz.cz. Clearly a missing trailing "." on the CNAME RHS, which creates a CNAME loop, and so TLSA lookups ServFail. I don't know whether fixing this is something that active24 can be expected to do. It may well be that each customer is fully in control of whatever data, good or bad, appears in their zone file, and it is not up to the hoster to attempt to fix it... _25._tcp.mflight.cz. IN TLSA ? ; ServFail AD=0 _25._tcp.gurmanunicov.cz. IN TLSA ? ; ServFail AD=0 _25._tcp.bdsoft.cz. IN TLSA ? ; ServFail AD=0 _25._tcp.kotatko-kamenivo-kura.cz. IN TLSA ? ; ServFail AD=0 _25._tcp.talka.cz. IN TLSA ? ; ServFail AD=0 _25._tcp.electrochmelar.cz. IN TLSA ? ; ServFail AD=0 _25._tcp.greif-cz.cz. IN TLSA ? ; ServFail AD=0 -- Viktor. From ietf-dane at dukhovni.org Mon Nov 13 05:42:30 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 13 Nov 2017 04:42:30 +0000 Subject: Gmail outbound stats to DANE-enabled domains In-Reply-To: <20170325205044.GQ26167@straasha.imrryr.org> References: <20170325205044.GQ26167@straasha.imrryr.org> Message-ID: <20171113044230.GG29327@mournblade.imrryr.org> Back in March I wrote: > 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. This "metric" is made available to me informally, so I avoid asking too frequently. The latest update shows: +---------------+---------------------+------------+ | total_domains | mail_from_5_senders | gt_50_msgs | +---------------+---------------------+------------+ | 173181 | 13393 | 2076 | +---------------+---------------------+------------+ which uses a slightly different "cut-off" of 5 senders rather than 10, so we don't have a direct comparison, but this should be the metric going forward. We we have > 13k domains that get traffic from multiple senders, and > 2k domains with evidence of sustained traffic (over the 8 day sample size). Just in case this is not clear, Gmail is not presently using DANE outbound, rather I send them a list of DANE domains from time to time, and get back the above numbers. -- Viktor. From ietf-dane at dukhovni.org Wed Nov 29 05:42:33 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 Nov 2017 04:42:33 +0000 Subject: Update on stats 2017-11 Message-ID: <20171129044233.GI29327@mournblade.imrryr.org> Summary: The number of DANE-enabled domains that have also been sighted on Google's email transparency report has increased from 122 to 125. The total domain count has increased from 172120 to 173857. The number DNSSEC domains in the survey stands at 5015834, thus DANE TLSA is deployed on 3.4% of domains with DNSSEC. Many DNSSEC domains use third-party MX hosts, that don't have DNSSEC, so they can't benefit from DANE until their providers secure the MX hosts. Please ask your provider to enable DNSSEC and DANE on their MX hosts. As of today I count 173857 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: 68513 domeneshop.no 61900 transip.nl 18440 udmedia.de 6396 bhosted.nl 1785 nederhost.net 1284 yourdomainprovider.net 1012 ec-elements.com 507 core-networks.de 391 omc-mail.com 349 mailbox.org 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 2969 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. There are 3672 distinct MX host certificates matched by the server's TLSA RRset. The number of published MX host TLSA RRsets found is 4409. These cover 4659 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 125 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 76 are in recent reports: gmx.at mail.de ouderportaal.nl travelbirdbelgie.be posteo.de overheid.nl nic.br ruhr-uni-bochum.de pathe.nl registro.br tum.de uvt.nl gmx.ch uni-erlangen.de xs4all.nl open.ch unitybox.de domeneshop.no anubisnetworks.com unitymedia.de webcruitermail.no gmx.com web.de debian.org isavedialogue.com egmontpublishing.dk freebsd.org mail.com tilburguniversity.edu gentoo.org solvinity.com enron.email ietf.org t-2.com octopuce.fr isc.org trashmail.com comcast.net lazarus-ide.org xfinity.com dd24.net netbsd.org xfinityhomesecurity.com gmx.net openssl.org xfinitymobile.com hr-manager.net samba.org nic.cz t-2.net torproject.org bayern.de xs4all.net asf.com.pt bund.de asp4all.nl handelsbanken.se fau.de bhosted.nl minmyndighetspost.se freenet.de bit.nl skatteverket.se gmx.de boozyshop.nl t-2.si jpberlin.de hierinloggen.nl mail.co.uk lrz.de otvi.nl govtrack.us Of the ~174000 domains, 780 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 198. Below is a list of the 101 underlying MX hosts that serve these domains and whose TLSA records don't match reality: Hall of Shame: white.agoracon.at mx2.spam-sponge.de mail.misbegotten.net mail.dipietro.id.au mx3.spam-sponge.de oostergo.net asp-mxtest.belnet.be mx1.spamsponge.de mx2.oostergo.net eufront.stansoft.bg mx2.spamsponge.de wfbrace.net eumembers.stansoft.bg mx3.spamsponge.de mx2.wfbrace.net andbraiz.com mx10.timotoups.de mx2.cbrace.nl mail.digitalwebpros.com fsck.email mx3.cbrace.nl mail.dnsmadefree.com smtp.flipmail.es mail.fscker.nl smtp-1.httrack.com mail.0pc.eu smtp1.lococensus.nl mail.itsmine.com mail.antoineducret.eu smtp2.lococensus.nl demo.liveconfig.com mail2.cesidianroot.eu avs.mymailcleaner.nl mx04.mykolab.com gamepixel.eu mail.myzt.nl mail.noneuclideanconcepts.com webmail.kassoft.eu nuj-netherlands.nl lon-do.pieterpottie.com smtp.skolovi.eu mx2.nuj-netherlands.nl ny-do.pieterpottie.com mail2.subse.eu bounder.steelyard.nl ma.qbitnet.com smtp.vdlaken.eu mail.abanto-zierbena.org stmics01.smia-automotive.com mx.quentindavid.fr eumembers.datacentrix.org romulus.wittsend.com servmail.fr genius.konundrum.org mail.zx.com mail.demongeot.info mx2.maicolepape.org mx.bels.cz mail.nonoserver.info smtp2.amadigi.ovh mail.davidbodnar.cz mx1.email.youwerehere.info smtp3.amadigi.ovh gaia.nfx.cz mx2.email.youwerehere.info itaskmanager.ovh petg.cz node1.mxbackup.io mail.bacrau.ro mail.seslost.cz mail.rapidfuse.io mail.itconnect.ro mail.zionbit.cz mail.lsd.is mx.itconnect.ro mail.absynth.de mail.laukas.lt mail.pasion.ro mail.all4.de mx.datenknoten.me mail.familie-sander.rocks badf00d.de mx.giesen.me mx1.shevaldin.ru mail.denniseffing.de rootbox.me halon.gislaved.se mail.friehm.de mail.adeline.mobi halon02.gislaved.se mutt.lsexperts.de mail.castleturing.net mail.labbrack.se www.mtg.de mail.culm.net mail.rostit.se mail.ocmenzel.de anubis.delphij.net mail.xn----ymcadjpj1at5o.xn--wgbh1c mx1.spam-sponge.de mail.efflam.net Some recently notified, but the number of long-term problem MX hosts has been slowly creeping up... Please make sure to monitor the validity of your TLSA records, and implement a reliable key rotation procedure. Let's Encrypt users in particular tend to forget that by default Let's Encrypt certificate renewal replaces both the key and certificate, please read: http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766 https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 When updating the certificate chain you need to temporarily pre-publish multiple TLSA records matching the current and future certificate: https://dane.sys4.de/common_mistakes#3 However, with "3 1 1" + "2 1 1", the rollover process can be substantially simplified: http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 https://www.ietf.org/mail-archive/web/uta/current/msg01498.html After eliminating parked domains that do not accept email of any kind, the number of "real" email domains with bad DNSSEC support stands at 132. The top 6 (the rest have too few domains to include in a top 10) name server operators with problem domains are: 22 firstfind.nl 7 active24.cz 5 tse.jus.br 4 ignum.com 4 glbns.com 4 army.mil Only 7 of the DNS-broken domains appear in historical Google Email transparency reports: idaho.gov nsysu.edu.tw tse.jus.br rotterdam.nl tiviths.com.br trtrj.jus.br tre-ce.jus.br The problem DNS queries are: _25._tcp.mx.tiviths.com.br _25._tcp.mx1.trtrj.jus.br _25._tcp.dexter.tse.jus.br _25._tcp.lalavava.tse.jus.br _25._tcp.mandark.tse.jus.br _25._tcp.inbound.idaho.gov _25._tcp.mail.rotterdam.nl _25._tcp.barracuda.nsysu.edu.tw [ See , Much of the TLSA non-response issue seems to be related to a "feature" of some 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 an 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. [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.