- dane-users - list.sys4.de

improvement suggestion
by Andreas Schulze 09 Jun '16

09 Jun '16

Hello, we have a message to *(a)transfennica.com. Postfix lookup the MX ( mail.spliethoff.nl) and try to validate vi DANE. That fail: Jun 9 11:55:00 mail postfix/smtp[12345]: warning: TLS policy lookup for transfennica.com/mail.spliethoff.nl: TLSA lookup error for mail.spliethoff.nl:25 Jun 9 11:55:00 mail postfix/smtp[12345]: warning: TLS policy lookup for transfennica.com/smtp.spliethoff.nl: TLSA lookup error for smtp.spliethoff.nl:25 Jun 9 11:55:00 mail postfix/smtp[12345]: QUEUEID: to=<postmaster(a)transfennica.com>, relay=none, delay=0.75, delays=0.13/0/0.62/0, dsn=4.7.5, status=deferred (TLSA lookup error for smtp.spliethoff.nl:25) OK, I went to dane.sys4.de, (thanks for the service) but simply got "transfennica.com don't use DNSSEC" It would be helpful the validator would do the MX lookup and check the MX hosts like postfix does. Thanks, Andreas -- A. Schulze DATEV eG

2 1

Issues delivering mail from GMX to my postfix
by Carsten Strotmann (sys4) 23 May '16

23 May '16

Hi, I've got a report from a user that tries to send an mail from GMX to my private mail account. The mail-account is secured by DANE/TLSA and running on Postfix. "dane.sys4.de" does not report any issues, but GMX refuses to deliver mail with this message: ----------------------------schnipp---------------------------- This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: cas(a)strotmann.de: remote MX does not support STARTTLS ----------------------------schnipp---------------------------- Has anyone seen a similar issue? Any ideas how to troubleshoot? Best regards Carsten

5 7

NEWSFLASH: DANE TLSA records published for web.de!
by Viktor Dukhovni 21 Apr '16

21 Apr '16

The web.de domain has just published DANE TLSA records for its MX hosts: web.de. IN MX 100 mx-ha02.web.de. ; AD=1 _25._tcp.mx-ha02.web.de. IN TLSA 3 1 1 409c9e91a2a9f4d7881dbf0094b3839d4343a4a57d9bf559fdeb0c1f4c5b8b3e ; passed Subject = CN=mx-ha02.web.de,emailAddress=server-certs(a)1und1.de,L=Montabaur,ST=Rhineland-Palatinate,O=1&1 Mail & Media GmbH,C=DE Issuer = CN=TeleSec ServerPass DE-2,street=Untere Industriestr. 20,L=Netphen,postalCode=57250,ST=Nordrhein Westfalen,OU=T-Systems Trust Center,O=T-Systems International GmbH,C=DE Inception = 2014-07-22T11:21:46Z Expiration = 2017-07-27T23:59:59Z web.de. IN MX 100 mx-ha03.web.de. ; AD=1 _25._tcp.mx-ha03.web.de. IN TLSA 3 1 1 33fccf0e82584b6133cf18d24ae592cc6cbc9cfcab13291a5585a2b20a30eb19 ; passed Subject = CN=mx-ha03.web.de,emailAddress=server-certs(a)1und1.de,L=Montabaur,ST=Rhineland-Palatinate,O=1&1 Mail & Media GmbH,C=DE Issuer = CN=TeleSec ServerPass DE-2,street=Untere Industriestr. 20,L=Netphen,postalCode=57250,ST=Nordrhein Westfalen,OU=T-Systems Trust Center,O=T-Systems International GmbH,C=DE Inception = 2014-07-22T11:22:46Z Expiration = 2017-07-27T23:59:59Z This is a major milestone in DANE adoption. -- Viktor.

4 4

education.lu
by Wolfgang Breyha 08 Apr '16

08 Apr '16

Hi! I'm testing the new exim 4.85 DANE support and it took only some days to get in trouble... One of our users tried to send mail to the domain education.lu. Their domain and MX hosts are DNSSEC enabled and have TLSA RRs. The DANE validator https://dane.sys4.de/smtp/education.lu says: "Unusable TLSA Records". Most likely because it is type 1 not allowed for DANE-SMTP? I've set hosts_try_dane = * in my SMTP transport. Exim refuses to talk to those hosts at all with "failure while setting up TLS session". Is this expected behavior in terms of DANE-SMTP? What's postfix doing in this case? Greetings, Wolfgang -- Wolfgang Breyha <wbreyha(a)gmx.net> | http://www.blafasel.at/ Vienna University Computer Center | Austria

8 29

Re: Small uptick in domains with long-term incorrect TLSA records
by Viktor Dukhovni 29 Feb '16

29 Feb '16

I am presently tracking 28 domains with wrong TLSA records that show no sign that they are likely to be fixed soon. Of these 19 are the same as last time: 1post.de 3nw.de allispdv.com.br auxio.org bebidaliberada.com.br bels.cz castleturing.net comseo.com.br f2h.at lastsip.com linlab.net nevodnet.com planissimo.fr prodnsbr.com.br simplesestudio.com.br solucoesglobais.com.br twsolutions.net.br www.co.tt zx.com the good news is that 5 of the previus 25 have been addressed, but on the other hand 9 new ones have been added: 101host.de barbarassecret.com conjur.com.br lojabrum.com.br netlig.com.br nonoserver.info reich-trade.ch stric.se ticketmt.com.br Don't let your own domains linger with incorrect TLSA RRs. The stats at present: ~11500 passed 29 failed On the DNS front, still waiting for isphuset.no to upgrade PowerDNS, and the mail.mil nameservers are still blocking TLSA record lookups. -- Viktor.

1 0

New tools in Postfix 3.1-20160207
by Viktor Dukhovni 17 Feb '16

17 Feb '16

It will soon (when 3.1 is released this month) be much easier to manage your certificates and TLSA records with Postfix: http://www.postfix.org/TLS_README.html#built-in http://www.postfix.org/postfix-tls.1.html This only supports DANE-EE(3) "3 1 1" TLSA records at present, but should simplify interaction with Let's Encrypt by generating the CSR for you, and separates creation of keys/certs from deployment, giving you the opportunity to update the TLSA records first, let the old records expire from secondary nameservers and caches and then deploy... -- Viktor.

2 1

postbank.de / dslbank.de
by Andreas Schulze 03 Feb '16

03 Feb '16

Hallo, postbank.de is known (to me) as broken somehow. Today I noticed delivery problems to dslbank.de That focused my attention again to that unsolved issue. $ posttls-finger dslbank.de posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.mailrelay1.bonn.postbank.de type=TLSA: Host not found, try again posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.mailrelay1.bonn.postbank.de type=TLSA: Host not found, try again posttls-finger: Failed to establish session to dslbank.de via mailrelay1.bonn.postbank.de: TLSA lookup error for mailrelay1.bonn.postbank.de:25 posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.mailrelay2.bonn.postbank.de type=TLSA: Host not found, try again posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.mailrelay2.bonn.postbank.de type=TLSA: Host not found, try again posttls-finger: Failed to establish session to dslbank.de via mailrelay2.bonn.postbank.de: TLSA lookup error for mailrelay2.bonn.postbank.de:25 $ postconf mail_version mail_version = 3.0.3 $ postconf smtp_tls_security_level smtp_tls_security_level = dane $ dig _25._tcp.mailrelay1.bonn.postbank.de tlsa ... ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20811 ;_25._tcp.mailrelay1.bonn.postbank.de. IN TLSA ... -> SERVFAIL is the problem here. $ which_resolver_do_i_use unbound-1.5.x @ localhost But I wonder why dane.sys4.de tell me "No TLSA records." In fact there is some magic @sys4 that understand, postbank.de do not publish TLSA records. postfix do not know this magic and leave messages undelivered in my queue :-/ OK, I will now add the next whitelist entry to smtp_tls_policy_maps but that's no generic solution. Any hints are appreciated. Thanks, Andreas -- A. Schulze DATEV eG

7 10

Small uptick in domains with long-term incorrect TLSA records
by Viktor Dukhovni 03 Feb '16

03 Feb '16

Quick numbers update: * Top 3 DANE domain MX host providers (in my survey, real numbers much higher). A significant jump in the transip numbers recently: 5077 udmedia.de 1281 mx.transip.email 921 mx.nederhost.net * Total DANE SMTP domains: 10780 * Total primary MX hosts: 1568 * Top 10 DANE TLDs: 3856 com 2162 de 1333 net 1100 nl 541 org 426 eu 175 info 139 be 126 at 114 ch I've also noticed a growing presence of MX hosts of the form "box.example.com" with Let's Encrypt certificates and correctly rotated "3 1 1" TLSA records. These seem to be "mail in a box" deployments, that seem to just work. Kudos to the "mail in a box" folks. And now to the subject of this message. Until quite recently, the number of domains with long-term erroneous incorrect records has been in the 10-15 range at any given time, out of a total of ~11,000 domains served by ~1600 MX hosts. In the last few weeks I see an uptick of domains whose TLSA records become wrong and stay that way after sloppy key rotation. A noticeable fraction (though not the majority) of the problem domains have recently deployed "Let's Encrypt" certificates, without taking their TLSA records into account. Please take care to handle key rotation correctly. In Postfix 3.1, which should be released soon (likely this month), there will with any luck be a new tool to help administrators manage keys, certificates, CSRs and TLSA records. I'll post pointers to documentation once this is available. In the mean time, please don't forget: https://dane.sys4.de/common_mistakes#3 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 http://tools.ietf.org/html/rfc7671#section-5.2 I am now tracking 25 broken domains that show no sign that they are likely to be fixed soon: f2h.at allispdv.com.br bebidaliberada.com.br comseo.com.br imagemdigital.com.br mypst.com.br prodnsbr.com.br simplesestudio.com.br solucoesglobais.com.br twsolutions.net.br 4nettech.com lastsip.com nevodnet.com zx.com bels.cz 1post.de 3nw.de neuhaus-city.de tsimnet.eu planissimo.fr castleturing.net linlab.net auxio.org konundrum.org www.co.tt If anyone on this list either operates one of these, or knows the administrators, please help to get these resolved. There are 11 more broken domains that are less than a week old, I am hoping some of those will be repaired in the near term, but a few may join the chronically-ill list. If anyone on this list is in Brazil, perhaps there's a language barrier that's making it more difficult for .br sites to know what to do, or respond to notices of problems. It would be great if there a were a .br version of dane.sys4.de with "common_mistakes" in Portuguese. -- Viktor.

1 1

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA
by Viktor Dukhovni 15 Dec '15

15 Dec '15

[ FYI, from postfix-users ] > On Dec 14, 2015, at 2:57 PM, Jacob Hoffman-Andrews <jsha(a)eff.org> wrote: > > On 12/14/2015 11:23 AM, Viktor Dukhovni wrote: >> May I ask for your help in providing configuration guidance to LE >> users who also plan to publish DANE TLSA records. > > I'd be happy to help, but am a little constrained on time. If you've got > time, would you mind posting a quick explanation at > https://community.letsencrypt.org/c/server-config of why "3 0 1" records > are risky with LE certificates, and the alternatives? I think the email > below is a good start, and if you prefer not to create an account on our > forums I could repost it with permission. I'll then pin the post for > some time to make people see it. Thanks. https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-… -- Viktor.

1 0

Deployment news (comcast.net publishes TLSA RRs)
by Viktor Dukhovni 21 Nov '15

21 Nov '15

Today comcast.net published TLSA records for their MX hosts. comcast.net. IN MX 5 mx1.comcast.net. comcast.net. IN MX 5 mx2.comcast.net. _25._tcp.mx1.comcast.net. IN TLSA 3 1 1 90e2f742b459860c0bbf1343b5a36bc5842a3f45056d30bf25dbb475a62eca47 _25._tcp.mx2.comcast.net. IN TLSA 3 1 1 c8cb2faa4c0b92cb3fd37e61eb4671744055f123c14c0dd31e8d92c379f9f8a3 $ posttls-finger -c -Lsummary -o inet_protocols=ipv4 "[mx1.comcast.net]" posttls-finger: Verified TLS connection established to mx1.comcast.net[96.114.157.80]:25: TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits) $ posttls-finger -c -Lsummary -o inet_protocols=ipv4 "[mx2.comcast.net]" posttls-finger: Verified TLS connection established to mx2.comcast.net[68.87.20.5]:25: TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits) Congratulations and thanks to Comcast. They are the first major US email provider to do so. Let's hope their lead will be followed by many others. My ongoing survey has now found 9389 working DANE domains. Most of these are served by a few domain hosting providers: 5230 udmedia.de 955 nederhost.net 354 transip.email 47 mediaweb-it.net 45 mailbox.org 36 gr-webdesign.de 32 core-networks.de 32 wk-serv.net 30 set-hosting.de 30 dotplex.de The actual numbers of DANE-enabled hosted domains is much larger, for example udmedia alone reportedly has over 25 thousand. My lists of candidate domains to test are far from complete. Of these 9389, there are now 28 domains (up from 27 yesterday now that comcast.net is live) that are "large enough" to be listed in Google's email transparency report: conjur.com.br jpberlin.de comcast.net freebsd.org mypst.com.br lrz.de rrpproxy.net ietf.org registro.br posteo.de t-2.net isc.org societe.com ruhr-uni-bochum.de aanbodpagina.nl netbsd.org t-2.com tum.de xs4all.nl openssl.org bayern.de unitymedia.de debian.org samba.org bund.de lepartidegauche.fr eu.org torproject.org On the "problem" front. The following DNS hosters still have some issues with correct DNSSEC "denial of existence": #Domains Provider -------- ---------- 33 binero.se (resolution in progress) 28 isphuset.no (issue acknowledged) 15 axc.nl (notified) 11 papaki.gr (notified) 5 forpsi.net (notified) And 10 "small" domains currently publish incorrect TLSA records: bebidaliberada.com.br solucoesglobais.com.br nevodnet.com zx.com 1post.de geekify.de wx0.de tsimnet.eu konundrum.org www.co.tt If anyone reading this happens to know a usable contact for the above, please let them know their TLSA records need updates. Finally, I have a list of ~97000 domains that have DNSSEC and at least one "primary" MX host has DNSSEC, but no TLSA records are published as yet. These domains are good candidates for DANE deployment, it is just a matter of deciding out of whether to use "3 1 1" end-entity records or "2 0 1" trust-anchor records, and documenting a key/cert rotation procedure: https://tools.ietf.org/html/rfc7671#section-5.1 https://tools.ietf.org/html/rfc7671#section-5.2 As always, don't forget: https://dane.sys4.de/common_mistakes#3 https://dane.sys4.de/common_mistakes#6 https://tools.ietf.org/html/rfc7671#section-8.1 https://tools.ietf.org/html/rfc7671#section-8.4 -- Viktor.

2 8