January 2018 - dane-users

dane.sys4.net IPv6 problem
by Karol Augustin 22 Jan '18

22 Jan '18

Hi, Until recently I was using HE tunnel as IPv6 provider until AWS enabled native IPv6 support in my region and everything was working without problems. Since I have enabled native IPv6 on my mail server and have problem with DANE tester site https://dane.sys4.de/smtp/augustin.pl It always times out on IPv6 address and I am confident that everything is configured properly as I receive lots of connections by IPv6 including gmail, Debian and Postfix mailing lists etc. Jan 20 06:32:38 mail postfix/postscreen[17537]: CONNECT from [2604:8d00:0:1::4]:54406 to [2a05:d018:76d:5af6:d050:9b30:6bf7:df98]:25 Jan 20 06:32:38 mail postfix/postscreen[17537]: WHITELISTED [2604:8d00:0:1::4]:54406 Jan 20 06:32:38 mail postfix/smtpd[17538]: connect from russian-caravan.cloud9.net[2604:8d00:0:1::4] Jan 20 06:32:39 mail postfix/smtpd[17538]: Trusted TLS connection established from russian-caravan.cloud9.net[2604:8d00:0:1::4]: TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits) You can see test results here: https://network-tools.webwiz.net/email-test.htm?email=augustin%2Epl&connect… Is there any known problem with DANE tester IPv6 configuration? I appreciate your help. Karol -- Karol Augustin karol(a)augustin.pl http://karolaugustin.pl/

3 7

http://dnsviz.net/d/_25._tcp.sisim1.systemec.nl/dnssec/
by Andreas Schulze 17 Jan '18

17 Jan '18

Hello, we found messages to MONTAGEBEDRIJFVANDERPLUIJM.NL undeliverable because postfix/unbound could not fetch _25._tcp.sisim1.systemec.nl The nameservers deny the existence of _tcp.$MXhost.systemec.nl. As our unbound uses QNAME minimization that result in _25._tcp.$MXhost.systemec.nl. also fail. dig @ns.systemec.NL. _tcp.sisim2.systemec.NL any +dnssec ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.9.6-P1 <<>> @ns.systemec.NL. _tcp.sisim2.systemec.NL any +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 769 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1680 ;; QUESTION SECTION: ;_tcp.sisim2.systemec.NL. IN ANY ;; AUTHORITY SECTION: systemec.NL. 3600 IN SOA ns.systemec.NL. postmaster.systemec.NL. 2017113006 28800 7200 604800 3600 systemec.NL. 3600 IN RRSIG SOA 14 2 3600 20180125000000 20180104000000 39248 systemec.nl. mtn3UO0IJXb1WA+2qEp7kYTlqaOAU7qrUcizVJCLQ6Tuda4qgd7fPAO5 qZY9FBQdiP/l4YEEeooZJyMtQilHlLiDK7MBIarIjdNSF2qQrk5hfo1a LJzs5pNW1upEdR51 sisim2.systemec.NL. 3600 IN NSEC _25._tcp.sisim2.systemec.nl. A RRSIG NSEC sisim2.systemec.NL. 3600 IN RRSIG NSEC 14 3 3600 20180125000000 20180104000000 39248 systemec.nl. UUcvXFNUVhyOUHka2Md64YKUNVownhfBsly32lqxHYKJ62JV4/x1XXV/ ckROX7CmON8MvNyVAB8FC1p1qGdjOo+Df1jpJ7oduukbEOqCeOVWdQbO 29CrRHe+84Wl/6iz ;; Query time: 18 msec ;; SERVER: 89.20.90.102#53(89.20.90.102) ;; WHEN: Wed Jan 17 11:03:38 CET 2018 ;; MSG SIZE rcvd: 429 The expected answer is "NOERROR" because the are no valid RRs for that label bit there exist childs ( _25. ) Is the correct term for that "ENT" "Empty non terminal" ??? Maybe someone can relay that information to systemec.nl DNS admins. We implemented a workaround via smtp_tls_policy_maps: "$DOMAIN -> may" until that is fixed. -- A. Schulze DATEV eG

1 1

EU Commission formally recognizes DANE
by Bart Knubben 12 Jan '18

12 Jan '18

Hi, "The European multi-stakeholder platform on ICT standardisation evaluated and gave a positive advice to the identification of the following technical specifications for referencing in public procurement: 'SPF-Sender Policy Framework for Authorizing Use of Domains in Email' ('SPF'), 'STARTTLS-SMTP Service Extension for Secure SMTP over Transport Layer Security' ('STARTTLS-SMTP') and 'DANE-SMTP Security via Opportunistic DNS-Based Authentication of Named Entities Transport Layer Security' ('DANE-SMTP') developed by Internet Engineering Task Force (IETF); [...] The evaluation and advice of the platform was subsequently submitted to consultation of sectoral experts who confirmed the positive advice to its identification." "THE EUROPEAN COMMISSION, [...] HAS ADOPTED THIS DECISION: Article 1, The technical specifications listed in the Annex are eligible for referencing in public procurement." For more details please see: http://eur-lex.europa.eu/ legal-content/EN/TXT/?qid=1515759784644&uri=CELEX:32017D2288 -- Best regards, Bart Knubben

1 0

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