- dane-users - list.sys4.de

Update on stats 2017-12
by Viktor Dukhovni 01 Jan '18

01 Jan '18

[ Happy New Year! May 2018 see major advances in DANE adoption and even fewer operational issues. ] Summary: The number of DANE-enabled domains that have also been sighted on Google's email transparency report has increased from 125 to 127 The total domain count has increased from 173857 to 176079. The number DNSSEC domains in the survey stands at 5096318, thus DANE TLSA is deployed on 3.46% 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. [ It would be especially significant if "redirect.ovh.net" were to implement DNSSEC+DANE, if someone personally knows the right people to gently nudge at ovh.net, please do. ] As of today I count 176079 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: 68824 domeneshop.no 63076 transip.nl 18510 udmedia.de 6318 bhosted.nl 1767 nederhost.nl 1265 yourdomainprovider.net 1003 ec-elements.com 516 core-networks.de 395 omc-mail.com 370 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. 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): 1277 GeoIP Country Edition: DE, Germany 770 GeoIP Country Edition: US, United States 450 GeoIP Country Edition: NL, Netherlands 321 GeoIP Country Edition: FR, France 149 GeoIP Country Edition: GB, United Kingdom 102 GeoIP Country Edition: CZ, Czech Republic 74 GeoIP Country Edition: CA, Canada 62 GeoIP Country Edition: CH, Switzerland 60 GeoIP Country Edition: SE, Sweden 58 GeoIP Country Edition: BR, Brazil IPv6 is still comparatively rare for MX hosts, and the top 11 countries by DANE MX host IPv6 GeoIP are: 212 GeoIP Country V6 Edition: DE, Germany 103 GeoIP Country V6 Edition: US, United States 100 GeoIP Country V6 Edition: NL, Netherlands 56 GeoIP Country V6 Edition: FR, France 29 GeoIP Country V6 Edition: GB, United Kingdom 23 GeoIP Country V6 Edition: CZ, Czech Republic 8 GeoIP Country V6 Edition: SE, Sweden 7 GeoIP Country V6 Edition: SG, Singapore 7 GeoIP Country V6 Edition: NO, Norway 7 GeoIP Country V6 Edition: ID, Indonesia 7 GeoIP Country V6 Edition: CH, Switzerland There are 3018 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 4652. These cover 4742 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 128 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 73 are in recent reports: gmx.at lrz.de ouderportaal.nl travelbirdbelgie.be mail.de overheid.nl travelbirdbelgique.be posteo.de pathe.nl nic.br ruhr-uni-bochum.de uvt.nl registro.br tum.de xs4all.nl gmx.ch uni-erlangen.de domeneshop.no open.ch unitybox.de handelsbanken.no switch.ch unitymedia.de webcruitermail.no anubisnetworks.com web.de aegee.org gmx.com egmontpublishing.dk debian.org isavedialogue.com netic.dk freebsd.org mail.com tilburguniversity.edu gentoo.org solvinity.com octopuce.fr ietf.org t-2.com comcast.net isc.org trashmail.com dd24.net netbsd.org xfinity.com dns-oarc.net openssl.org xfinityhomesecurity.com gmx.net samba.org xfinitymobile.com hr-manager.net torproject.org nic.cz mpssec.net asf.com.pt bayern.de t-2.net handelsbanken.se bund.de xs4all.net t-2.si fau.de bhosted.nl mail.co.uk freenet.de boozyshop.nl govtrack.us gmx.de hierinloggen.nl jpberlin.de otvi.nl Of the ~176000 domains, 785 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 192. Below is a list of the 102 underlying MX hosts that serve these domains and whose TLSA records don't match reality: Hall of Shame: white.agoracon.at mx2.pfp.de mail.diejanssens.net mail.dipietro.id.au mail.rleh.de mail.efflam.net mx.krb.srv.pique.net.au mail.schwaho.de mail.lnaze.net zebulon.pique.net.au mx1.spam-sponge.de mail.misbegotten.net eufront.stansoft.bg mx2.spam-sponge.de wfbrace.net eumembers.stansoft.bg mx3.spam-sponge.de mx2.wfbrace.net mail.advokatur4a.ch mx1.spamsponge.de mx2.cbrace.nl andbraiz.com mx2.spamsponge.de mx3.cbrace.nl mail.digitalwebpros.com mx3.spamsponge.de mail.fscker.nl mail.dnsmadefree.com mx10.timotoups.de smtp1.lococensus.nl smtp-1.httrack.com fsck.email smtp2.lococensus.nl mail.i-bible.com mail.0pc.eu mail.myzt.nl demo.liveconfig.com mail2.cesidianroot.eu nuj-netherlands.nl mx01.mykolab.com gamepixel.eu mx2.nuj-netherlands.nl mx02.mykolab.com webmail.kassoft.eu bounder.steelyard.nl mx04.mykolab.com smtp.skolovi.eu mail.abanto-zierbena.org srv2.noneuclideanconcepts.com mail2.subse.eu smtp2.briaeros007.org ma.qbitnet.com smtp.vdlaken.eu eumembers.datacentrix.org stmics01.smia-automotive.com mx.quentindavid.fr genius.konundrum.org stmics02.smia-automotive.com servmail.fr smtps.planchon.org romulus.wittsend.com mail.demongeot.info smtp2.amadigi.ovh mail.zx.com mail.nonoserver.info smtp3.amadigi.ovh mx.bels.cz mx1.email.youwerehere.info mail.bacrau.ro mail.davidbodnar.cz mx2.email.youwerehere.info mail.itconnect.ro mail1.dolnipodluzi.cz mail.rapidfuse.io mx.itconnect.ro mail.machkovi.cz mail2.galax.is mail.pasion.ro gaia.nfx.cz mail.lsd.is mail.familie-sander.rocks petg.cz mx.datenknoten.me mx1.shevaldin.ru mail.zionbit.cz mx.giesen.me halon.gislaved.se mail.absynth.de rootbox.me halon02.gislaved.se mail.all4.de mail.amsx.net mail.labbrack.se mx2.mindrun.de mail.castleturing.net mail1.puggan.se www.mtg.de mail.culm.net mail.rostit.se mail.ocmenzel.de anubis.delphij.net mail.xn----ymcadjpj1at5o.xn--wgbh 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… https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766 https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certifi… https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-… 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… 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 116. The top 6 (the rest have too few domains to include in a top 10) name server operators with problem domains are: 24 firstfind.nl 7 active24.cz 5 tse.jus.br 4 ignum.com 4 glbns.com 4 army.mil Only 2 DNS-broken domains have no working nameservers and also appear in historical Google Email transparency reports: tiviths.com.br trtrj.jus.br The problem DNS queries are: _25._tcp.mx.tiviths.com.br _25._tcp.mx1.trtrj.jus.br [ See <https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08>, 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.

1 0

Update on stats 2017-11
by Viktor Dukhovni 29 Nov '17

29 Nov '17

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… https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766 https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certifi… https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-… 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… 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 <https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08>, 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.

1 0

Update on stats
by Viktor Dukhovni 13 Nov '17

13 Nov '17

As of today I count 137620 domains with correct DANE TLSA records for SMTP. 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 10 MX host providers by domain count are: 60764 domeneshop.no 43961 transip.nl 15734 udmedia.de 3040 bhosted.nl 1493 nederhost.net 904 ec-elements.com 431 core-networks.de 307 uvt.nl 301 bit.nl 287 omc-mail.com The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, in particular .de, .nl and .no. There are 2449 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. Alternatively, a similar number is seen in the count (2613) of distinct MX host server certificates that support the same ~137000 domains. A related number is 4172 TLSA RRsets found for MX host TCP port 25. This includes secondary MX hosts and domains none of whose primary MX hosts have TLSA records. The number of domains that at some point were listed in Gmail's email transparency report is now 105 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 56 are in recent reports (March 2017): gmx.at jpberlin.de overheid.nl nic.br lrz.de pathe.nl registro.br mail.de wooniezie.nl gmx.ch posteo.de xs4all.nl open.ch ruhr-uni-bochum.de domeneshop.no anubisnetworks.com tum.de webcruitermail.no gmx.com uni-erlangen.de debian.org mail.com unitymedia.de domainmail.org piratenexus.com web.de freebsd.org pirateperfection.com enron.email gentoo.org pre-sustainability.com octopuce.fr ietf.org t-2.com comcast.net netbsd.org trashmail.com dd24.net netcoolusers.org xfinity.com gmx.net openssl.org bayern.de hr-manager.net samba.org bund.de t-2.net torproject.org elster.de xs4all.net minmyndighetspost.se fau.de asp4all.nl skatteverket.se gmx.de ouderportaal.nl 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. Of the ~137000 domains, 655 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 96 (~30 are recent additions that may be resolved soon, the remaining ~60 are the for now stable population of broken domains). This month I'm posting the list of the 44 underlying MX hosts that serve these domains and whose TLSA records don't match reality. Hall of Shame: mail.dipietro.id.au www.mtg.de mail.inu.nl clubeararaquarense.org.br mx1.spamsponge.de mail.jekuiken.nl mail.antiphishing.ch mail.nonoserver.info mail.myzt.nl mail.digitalwebpros.com mx.datenknoten.me bounder.steelyard.nl mail.dnsmadefree.com mx.giesen.me mx.wm.net.nz demo.liveconfig.com mail.castleturing.net baobrien.org ny-do.pieterpottie.com datawebb.dafcorp.net smtp.copi.org diablo.sgt.com anubis.delphij.net eumembers.datacentrix.org tusk.sgt.com dorothy.goldenhairdafo.net smtp2.amadigi.ovh mx.bels.cz hs.kuzenkov.net webmail.headsite.se johniez.cz oostergo.net protector.rajmax.si mail.pksvice.cz ren.warunek.net arch-server.hlfh.space srv01.101host.de mail.e-rave.nl mail.blackcherry-management.co.uk mail.cdbm.de mail.hhsk.nl email.themcintyres.us mail.manima.de box.inpoint-mailt.nl The number of domains with bad DNSSEC support is 322. The top 10 DNS providers (by broken domain count) are: 52 axc.nl - Slated to be resolved 38 infracom.nl - Slated to be resolved 18 loopia.se 18 active24.cz 14 jsr-it.nl 12 rdw.nl 9 cas-com.net 8 metaregistrar.nl 6 tiscomhosting.nl 6 thednscompany.com Around 60 of the broken domains have at least one working nameserver, and so are email-reachable, given enough retries. -- Viktor.

1 1

Belated update on stats 2017-09/2017-10
by Viktor Dukhovni 11 Nov '17

11 Nov '17

[ Sorry about the delay, I was too busy rewriting major chunks of the underlying code to produce a report. Better late than never so the below is the status for today, rather than the end of September. ] Summary: The number of DANE-enabled domains that have also been sighted on Google's email transparency report has increased from 115 to 122, while the number of DNS zones with TLSA-enabled primary MX hosts has increased from 2708 to 2999. The total domain count is largely unchanged from 172205 to 172120. A new type of TLSA record mismatch has cropped up, so far on just two MX hosts. Their RSA certificate chains match their TLSA records, but their ECDSA certificate chains do not: https://mail.sys4.de/pipermail/dane-users/2017-August/000416.html https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html As of today I count 172120 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: 68399 domeneshop.no 60915 transip.nl 18354 udmedia.de 6460 bhosted.nl 1787 nederhost.net 1294 yourdomainprovider.net 1009 ec-elements.com 505 core-networks.de 384 omc-mail.com 333 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. [ The DANE domain counts for the large providers appear to have plateaued in the past couple of months. Perhaps, absent new more comprehensive sources of live domain names, I've finally found as many domains I can reasonably expect to find for these providers, and there's not much growth in their "visible" domain portfolios. ] There are 2999 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. Alternatively, a similar number is seen in the count (2853) of distinct MX host server certificates that support the same ~172000 domains. The number of published MX host TLSA RRsets found is 3932. These cover 4004 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 122 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 70 are in recent reports (spanning Sep and Oct): gmx.at posteo.de overheid.nl travelbirdbelgie.be ruhr-uni-bochum.de pathe.nl nic.br tum.de uvt.nl registro.br uni-erlangen.de xs4all.nl gmx.ch unitybox.de domeneshop.no open.ch unitymedia.de webcruitermail.no anubisnetworks.com web.de debian.org gmx.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 minmyndighetspost.se fau.de bhosted.nl skatteverket.se freenet.de bit.nl t-2.si gmx.de boozyshop.nl mail.co.uk jpberlin.de hierinloggen.nl govtrack.us lrz.de otvi.nl mail.de ouderportaal.nl Of the ~172000 domains, 545 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 160. Below is a list of the 100 underlying MX hosts that serve these domains and whose TLSA records don't match reality: Hall of Shame: white.agoracon.at mail.manima.de mx2.wfbrace.net mail.dipietro.id.au mail.ocmenzel.de mx3.wfbrace.net asp-mxa.belnet.be supersahnetorten.de wfbrace.net asp-mxb.belnet.be mx.thorko.de mx2.cbrace.nl asp-mxtest.belnet.be mail.0pc.eu mx3.cbrace.nl eufront.stansoft.bg relay.antoineducret.eu mail.lajetee.nl eumembers.stansoft.bg mail2.cesidianroot.eu smtp1.lococensus.nl fazendeiro.ifba.edu.br gamepixel.eu smtp2.lococensus.nl mail.gna.ch webmail.kassoft.eu mail.myzt.nl andbraiz.com smtp.skolovi.eu mx2.nuj-netherlands.nl mx1.cloudfiltering.com mail2.subse.eu nuj-netherlands.nl mx2.cloudfiltering.com smtp.vdlaken.eu mail.solarisinternetgroep.nl mail.digitalwebpros.com mx.quentindavid.fr bounder.steelyard.nl mail.itsmine.com servmail.fr mail.abanto-zierbena.org demo.liveconfig.com mail.demongeot.info freebox.crans.org mx04.mykolab.com mail.nonoserver.info soyouz.crans.org intranet.nctechcenter.com node1.mxbackup.io eumembers.datacentrix.org mta1-em1.orleans.occnc.com mail.rapidfuse.io genius.konundrum.org mta3-em1.somerville.occnc.com mail.lsd.is smtp2.amadigi.ovh lon-do.pieterpottie.com mail.laukas.lt smtp3.amadigi.ovh ny-do.pieterpottie.com mx.datenknoten.me itaskmanager.ovh ma.qbitnet.com mx.giesen.me mail.bacrau.ro stmics01.smia-automotive.com rootbox.me club3d.ro stmics02.smia-automotive.com lima.ahrain.net mail.itconnect.ro mail.zx.com avarty.net mx.itconnect.ro mx.bels.cz mail.castleturing.net mail.pasion.ro mail.davidbodnar.cz mail.d3fy.net mail.familie-sander.rocks gaia.nfx.cz mail.efflam.net mx1.shevaldin.ru petg.cz mail.luyckx.net mail.labbrack.se mail.seslost.cz mail.misbegotten.net mail2.puggan.se mail.zionbit.cz mx2.oostergo.net mail.rostit.se mail.jo8.de oostergo.net mail.muthai.in.th mail.lanasoft.de mail.qusign.net mutt.lsexperts.de mail.roeller.net Some just notified, so I expect this to be a local peak. 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 Only 7 of the DNS-broken domains appear in historical Google Email transparency reports: tiviths.com.br tre-ce.jus.br trtrj.jus.br tse.jus.br idaho.gov nsysu.edu.tw The problem DNS queries are: _25._tcp.mx.tiviths.com.br. IN TLSA ? _25._tcp.dexter.tse.jus.br. IN TLSA ? _25._tcp.lalavava.tse.jus.br. IN TLSA ? _25._tcp.mandark.tse.jus.br. IN TLSA ? _25._tcp.inbound.idaho.gov. IN TLSA ? _25._tcp.mx1.trtrj.jus.br. IN TLSA ? _25._tcp.barracuda.nsysu.edu.tw. IN TLSA ? [ See <https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08>, 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.

1 1

New DANE TLSA monitoring/diagnostic utility
by Viktor Dukhovni 17 Sep '17

17 Sep '17

I am pleased to offer to the DANE user community a new monitoring and diagnostic utility. This is a one-shot variant of my survey code specialized for monitoring cron jobs and troubleshooting. Code and instructions at https://github.com/vdukhovni/danecheck While Haskell may be an unfamiliar programming development toolchain for many of you, I hope that it will not be difficult to install it for the purpose of compiling an existing project. See the README.md for build instructions. Enjoy. -- Viktor.

1 0

Ironic interaction of greylistiing, backup MX hosts and DANE
by Viktor Dukhovni 02 Sep '17

02 Sep '17

[ Also sent to the postfix-users(a)postfix.org list. ] I sent a "please fix your TLSA records" notice to "postmaster" and "info" at a domain whose primary MX host certificate fails to match its TLSA records: postfix/pickup[62805]: 7672C1DD39: ... postfix/cleanup[63835]: 7672C1DD39: message-id=<...> postfix/qmgr[844]: 7672C1DD39: from=<...>, size=8815, nrcpt=2 (queue active) postfix/smtp[63837]: 7672C1DD39: host mail.example.nl[192.0.2.1] said: 450 4.2.0 ... Greylisted, ... postfix/smtp[63837]: 7672C1DD39: to=<postmaster(a)example.nl>, relay=mail.example.nl[192.0.2.1]:25, delay=3.7, delays=0.03/0.01/1.5/2.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 119F07F861) postfix/smtp[63837]: 7672C1DD39: to=<info(a)example.nl>, relay=vps.example.nl[192.0.2.2]:25, delay=5.7, delays=0.03/0.01/5/0.61, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 2FBDC2064A) The "postmaster" account copy was accepted by the primary MX, but the "info" address was greylisted: *only* by the primary MX. However, the secondary MX accepts email *without* greylisting! This has the effect of delivering all mail via the secondary, with the primary never seeing any retries that cause greylisting to pass. What happened next was interesting and ironic. I got a "delay" notification from the secondary: Your message could not be delivered for more than 3 hour(s). It will be retried until it is 5 day(s) old. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <info(a)example.nl>: Server certificate not trusted The secondary is configured to verify DANE TLSA when relaying mail to the primary, so the problem report to "info", and indeed pretty much all mail to the system in question is queueing on the secondary MX host, waiting for the primary MX TLSA records to be fixed! Only "postmaster" email gets through to its destination (if the sending system does not validate TLSA records, which is naturally the case for my outbound "please fix your TLSA records" notices). The main lesson here is not implement Greylisting on only a subset of your MX hosts. Don't do that! 1. When greylisting, make sure that all MX hosts with equal or worse (higher) MX preference also greylist. 2. It is harmless (though less effective) to greylist only on (all) backup MX hosts, and skip greylisting on the primary. It is not a good idea to greylist on the primary, and not on the backups. 3. Monitor your DANE TLSA records, in such a way that notices of problems get through even when the TLSA records are stale. 4. Handle certificate rotation correctly. https://dane.sys4.de/common_mistakes#3 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-… https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certifi… With "3 1 1" + "2 1 1" TLSA records, the rollover process can be substantially simplified: https://www.ietf.org/mail-archive/web/uta/current/msg01498.html Happy greylisting and TLSA record publishing to you all... -- Viktor.

1 0

Update on stats 2017-08
by Viktor Dukhovni 31 Aug '17

31 Aug '17

Summary: Mostly the same as last month, but new code made possible more comprehensive coverage of domains with DNS issues. As a result, the number of reported DNS issues has increased by almost 75%. This is not an actual surge in DNS problems, rather just better reporting of the existing (still improving) landscape. The number of DANE-enabled domains that have also been sighted on Google's email transparency report has increased from 114 to 115, while the number of DNS zones with TLSA-enabled primary MX hosts has increased from 2668 to 2708. The domain count has increased from 171738 to 172205. A new type of TLSA record mismatch is starting to show up, so far on just two MX hosts. Their RSA certificate chains match their TLSA records, but their ECDSA certificate chains do not: https://mail.sys4.de/pipermail/dane-users/2017-August/000416.html https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html As of today I count 172205 domains with correct DANE TLSA records for SMTP. 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: 68968 domeneshop.no 60617 transip.nl 18365 udmedia.de 6576 bhosted.nl 1809 nederhost.net 1331 yourdomainprovider.net 1003 ec-elements.com 517 core-networks.de 378 omc-mail.com 326 bit.nl 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 2708 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. Alternatively, a similar number is seen in the count (2933) of distinct MX host server certificates that support the same ~172000 domains. A related number is 3585 matching TLSA RRsets found SMTP MX hosts. These cover 3708 distinct MX hosts (some of which clearly employ a shared certificate). The number of domains that at some point were listed in Gmail's email transparency report is 115 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 59 are in recent reports: gmx.at jpberlin.de ouderportaal.nl travelbirdbelgie.be lrz.de overheid.nl nic.br mail.de pathe.nl registro.br posteo.de xs4all.nl gmx.ch ruhr-uni-bochum.de domeneshop.no open.ch tum.de webcruitermail.no switch.ch uni-erlangen.de debian.org anubisnetworks.com unitymedia.de freebsd.org gmx.com web.de gentoo.org mail.com egmontpublishing.dk ietf.org solvinity.com enron.email isc.org trashmail.com octopuce.fr netbsd.org xfinity.com comcast.net openssl.org xfinityhomesecurity.com dd24.net samba.org bayern.de gmx.net torproject.org bund.de hr-manager.net asf.com.pt elster.de mpssec.net minmyndighetspost.se fau.de t-2.net skatteverket.se freenet.de xs4all.net t-2.si gmx.de asp4all.nl Of the ~172000 domains, 811 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 111. Below is a list of the 69 underlying MX hosts that serve these domains and whose TLSA records don't match reality: Hall of Shame: mail.dipietro.id.au mutt.lsexperts.de wfbrace.net eumembers.stansoft.bg mail.manima.de mx2.wfbrace.net mail.gna.ch mx1.spamsponge.de mx2.cbrace.nl andbraiz.com mx.thorko.de mx3.cbrace.nl mail.digitalwebpros.com mail.0pc.eu cinnamon.nl mail.itsmine.com webmail.kassoft.eu smtp1.gblt.nl demo.liveconfig.com mx.quentindavid.fr mail.initfour.nl mx04.mykolab.com servmail.fr smtp1.lococensus.nl intranet.nctechcenter.com upc.dircon.hu mail.myzt.nl ny-do.pieterpottie.com mail.demongeot.info nuj-netherlands.nl ma.qbitnet.com mail.nonoserver.info mx2.nuj-netherlands.nl diablo.sgt.com kd2.io mail.solarisinternetgroep.nl tusk.sgt.com node2.mxbackup.io bounder.steelyard.nl stmics01.smia-automotive.com mail.laukas.lt vanderbijlict.nl stmics02.smia-automotive.com mx.datenknoten.me mail.abanto-zierbena.org erg.verweg.com mx.giesen.me beerstra.org mx.bels.cz rootbox.me smtp.copi.org gaia.nfx.cz lima.ahrain.net eumembers.datacentrix.org mail.seslost.cz mail.castleturing.net smtp3.amadigi.ovh mail.3c7.de horse.cherrypet.net mail.pasion.ro mail.afaul.de mail.efflam.net mail.familie-sander.rocks awesome-mail.de hs.kuzenkov.net mail.rostit.se mail.denniseffing.de oostergo.net protector.rajmax.si The number of domains with bad DNSSEC support is 649. Most of the increase is from accenture.com domains, almost all likely parked, so the actual impact on email delivery is probably small to none. The top 10 name server operators with problem domains are: 145 accenture.com 61 jsr-it.nl 26 tiscomhosting.nl 26 active24.cz 21 firstfind.nl 18 bradesco.com.br 17 usda.gov 10 rotterdam.nl 10 loopia.se 10 fde.dk Around 79 of the broken domains have at least one working nameserver, and so are email-reachable, given enough retries. Only 5 of the DNS-broken domains appear in historical Google Email transparency reports: tiviths.com.br tre-ce.jus.br tre-sp.jus.br tse.jus.br nsysu.edu.tw The associated DNS lookup issues are: _25._tcp.mailhost.bncr.fi.cr. IN TLSA ? ; ServFail _25._tcp.barracuda.nsysu.edu.tw. IN TLSA ? ; ServFail _25._tcp.lalavava.tse.jus.br. IN TLSA ? ; timeout _25._tcp.mx.tiviths.com.br. IN TLSA ? ; timeout _25._tcp.mandark.tse.jus.br. IN TLSA ? ; timeout _25._tcp.dexter.tse.jus.br. IN TLSA ? ; timeout [ See <https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08>, Much of the TLSA non-response issue seems to be related to a "feature" of Arbor Networks 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 another 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 0

DANE for SMTP and TLS certificate agility
by Carsten Strotmann 31 Aug '17

31 Aug '17

Below a little text about TLS certificate agility and some pitfalls herein (thanks to Viktor and Patrick for input and review): The Transport Layer Protocol (TLS) supports the introduction of new key algorithms for x509 certificates. For a long time, keys based on the RSA algorithm were the only available choice. Nowadays, TLS also permits keys based on elliptic curve algorithms such as ECDSA. Other, new algorithms might follow in the future. Modern algorithms promise same or better security with less CPU usage and smaller key sizes. This makes the new algoritms interesting for operators of TLS secured services. However older software (on client or peer server side) might not support and understand the newer algorithms, so both the new and the old need be configured for some transition time. Ideally, both communicating endpoints will negotiate the best algorithm (in terms of security and performance) supported by both sides. The scheme of supporting multiple certificate key algorithms is called certificate agility. Care must be taken when multiple key algorithms are used in a TLS setup together with DNS-based Authentication of Named-Entities (DANE) as documented in RFC 7672 ([https://tools.ietf.org/html/rfc7672.html]). With SMTP-DANE, data authenticating the TLS certificates (the hashes of TLS certificate, hashes of the public key, or the full certificates) are stored in DNS, secured by DNSSEC. Upon connection, a delivering mail-server (MTA) will recieve the certificate chain from the destination MTA and will try to validate this certificate chain via the data stored in DNS as one or more TLSA resource records. The TLSA records contain either information on the leaf-node certificates (called DANE-EE(3)) or information about the certification authority (DATE-TA(2)). With DANE-EE(3) and TLS certificate agility in use, each distinct certificate that is configured on the server side does require it's own TLSA record containing either the hash of the certificate, hash of the public key of the certificate or the certificate itself. With DANE-TA(2), multiple TLSA-Records are only needed if the certificates are issued by different certification authorities (care must be taken to compare the CA keys in the certificate chain, as certain CA companies or "brands" are using different certificate authorities to sign x509 certificates). The postfix mail server supports certificate agility, in the example below two certificates are configured, one based on RSA keys, and a 2nd certificate using ECDSA keys: ,---- | # RSA certificate configuration | smtpd_tls_key_file=/etc/postfix/tls/rsa-key.pem | smtpd_tls_cert_file=/etc/postfix/tls/rsa-cert.pem | # ECDSA certificate configuration | smtpd_tls_eckey_file=/etc/postfix/tls/ecdsa-key.pem | smtpd_tls_eccert_file=/etc/postfix/tls/ecdsa-cert.pem `---- This configuration requires two separate DANE-EE(3) TLSA records in DNS, one for RSA and one for the ECDSA certificate. If both certifcates are issued from the same CA, only one DANE-TA(2) TLSA record is required. OpenSSL 1.0.x does not handle multiple chain files gracefully, and so both certificate chain files need to contain all the issuer CA certificates needed to validate either end-entity (leaf) certificate. This is fixed in OpenSSL 1.1.0. The selection of which certificate algorithm to use is based on the TLS handshake. Older TLS software prefers RSA over ECDSA, while some more modern software will have a preference for ECDSA. Today most DANE commandline tools (ldns-dane, gnutls-cli ...), as well as online DANE services such as the DANE SMTP Validator ([https://dane.sys4.de]), are only testing one certificate (based on the preference or configuration of the underlying TLS library used to implement the tools). A missing TLSA record can go unnoticed but can lead to rejection of mail. The DANE SMTP Validator will be updated to check all possible TLS certificate key algorithms. --- Carsten Strotmann

2 1

Update on stats 2017-07 (infracom.nl DNS resolved)
by Viktor Dukhovni 01 Aug '17

01 Aug '17

Summary: Mostly the same as last month, with significant progress on the DNS front, as infracom.nl's nameservers now handle TLSA lookups correctly (they now respond with valid denial of existence or actual TLSA records as appropriate). The number of DANE-enabled domains that have also been sighted on Google's email transparency report has increased from 111 to 114, while the number of DNS zones with TLSA-enabled MX hosts has increased from 2615 to 2668. The overall count has increased from 171460 to 171738. NOTE 1: This month I've begun the transition to new backend code for the survey. The main visible change is that MX hosts that are, despite RFC requirements, CNAMEs for the real underlying host are no longer excluded from the survey. This leads to a small bump in the reported domain count (+81) that is due to the code change. NOTE 2: The survey only includes domains at least of whose "primary" MX hosts has secure TLSA records. The previous survey code skipped past any MX hosts that provably (DNSSEC-validated) had neither IPv4 nor IPv6 addresses (secure NXDOMAIN or NODATA). The new survey code makes this more difficult, and I may at some point stop including these domains (613 at last count). As of today I count 171738 domains with correct DANE TLSA records for SMTP. 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 10 MX host providers by domain count are: 69168 domeneshop.no 60171 transip.nl 18330 udmedia.de 6611 bhosted.nl 1809 nederhost.net 1341 yourdomainprovider.net -- (includes former networking4all.net domains) 1002 ec-elements.com 512 core-networks.de 378 omc-mail.com 342 bit.nl 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 2668 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. Alternatively, a similar number is seen in the count (2910) of distinct MX host server certificates that support the same ~171000 domains (this month the count includes all the MX hosts, rather just a single primary MX). A related number is 3797 matching TLSA RRsets found for MX host TCP port 25. These certificates are vended by 3951 distinct MX hosts (some of which clearly employ a shared certificate). The number of domains that at some point were listed in Gmail's email transparency report is 114 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 56 are in recent reports: gmx.at lrz.de otvi.nl nic.br mail.de ouderportaal.nl registro.br posteo.de overheid.nl gmx.ch ruhr-uni-bochum.de pathe.nl open.ch tum.de uvt.nl anubisnetworks.com uni-erlangen.de xs4all.nl gmx.com unitymedia.de domeneshop.no mail.com web.de webcruitermail.no solvinity.com tilburguniversity.edu debian.org trashmail.com enron.email freebsd.org xfinity.com octopuce.fr gentoo.org xfinityhomesecurity.com comcast.net ietf.org bayern.de dd24.net isc.org bund.de gmx.net netbsd.org elster.de hr-manager.net openssl.org fau.de mpssec.net samba.org freenet.de t-2.net torproject.org gmx.de xs4all.net asf.com.pt jpberlin.de asp4all.nl Of the ~172000 domains, 888 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 101. Below is a list of the 55 underlying MX hosts that serve these domains and whose TLSA records don't match reality: Hall of Shame: mail.dipietro.id.au h-hibernia.olnis-net.de dorothy.goldenhairdafo.net eumembers.stansoft.bg mx1.spamsponge.de mail.iaelu.net mx.delphij.com mail.stmartin-schwabach.de hs.kuzenkov.net mail.digitalwebpros.com mx.thorko.de oostergo.net demo.liveconfig.com smtp.flipmail.es cinnamon.nl intranet.nctechcenter.com mail.0pc.eu mail.e-rave.nl ny-do.pieterpottie.com palinet.eu mail.jekuiken.nl diablo.sgt.com mx.quentindavid.fr mail.myzt.nl tusk.sgt.com servmail.fr bounder.steelyard.nl mx1.wittsend.com mail.nonoserver.info mail.abanto-zierbena.org mx.bels.cz mail.bax.is beerstra.org gaia.nfx.cz mail.laukas.lt eumembers.datacentrix.org mail.b0red.de mx.datenknoten.me smtp3.amadigi.ovh mail.bg-netzwerk.de mx.giesen.me mail.pasion.ro mail.denniseffing.de completelyunoriginal.moe puggan.se mutt.lsexperts.de mail.castleturing.net mail.rostit.se mail.manima.de horse.cherrypet.net protector.rajmax.si www.mtg.de anubis.delphij.net h-hibernia.olnis-Net.de goldenhairdafo.net The number of domains with bad DNSSEC support is 374. The top 10 DNS providers with problem domains are: 66 jsr-it.nl 26 active24.cz 25 tiscomhosting.nl 19 firstfind.nl 16 rdw.nl 9 metaregistrar.nl 9 ignum.com 8 ovh.net 8 loopia.se 7 rootdomains.nl Around 46 of the broken domains have at least one working nameserver, and so are email-reachable, given enough retries. Only 5 of the DNS-broken domains appear in historical Google Email transparency reports: tiviths.com.br tre-sp.jus.br trt1.jus.br trtrj.jus.br tse.jus.br The associated DNS lookup issues are: _25._tcp.mx.tiviths.com.br. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.mx.tiviths.com.br/dnssec/ _25._tcp.mx1.trt1.jus.br. IN TLSA ? ; zone signature failure: http://dnsviz.net/d/_25._tcp.mx1.trt1.jus.br/dnssec/ _25._tcp.mx1.trtrj.jus.br. IN TLSA ? ; zone signature failure: http://dnsviz.net/d/_25._tcp.mx1.trtrj.jus.br/dnssec/ _25._tcp.dexter.tse.jus.br. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.dexter.tse.jus.br/dnssec/ _25._tcp.lalavava.tse.jus.br. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.lalavava.tse.jus.br/dnssec/ _25._tcp.mandark.tse.jus.br. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.mandark.tse.jus.br/dnssec/ [ See <https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08>, Much of the TLSA non-response issue seems to be related to a "feature" of Arbor Networks 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 another 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 0

Comcast - Outbound DANE Announcement (comcast.net)
by Brotman, Alexander 18 Jul '17

18 Jul '17

Hello, Some time ago, Comcast rolled out TLSA records for senders to utilize when sending to "comcast.net" recipients, allowing senders to authenticate the certificates presented by our MTAs. In continuing support for DANE, we intend to deploy pilot code for outbound DANE this week, allowing us to do the same for traffic coming from our platform destined for other sites. We will pilot this with a few chosen domains that we've contacted and have made aware of our plans. Once we feel more comfortable with this, we will remove the restrictions and attempt DANE for all destination domains (with an exemption list for known-broken destination domains). If you would like to submit your domain to be part of the pilot, please drop me a note off-list. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast

1 0