From andreas.schulze at datev.de Tue Feb 2 12:43:50 2016 From: andreas.schulze at datev.de (Andreas Schulze) Date: Tue, 2 Feb 2016 12:43:50 +0100 Subject: postbank.de / dslbank.de Message-ID: <56B09676.7090007@datev.de> 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 From ml+dane-users at esmtp.org Tue Feb 2 12:55:33 2016 From: ml+dane-users at esmtp.org (ml+dane-users at esmtp.org) Date: Tue, 2 Feb 2016 03:55:33 -0800 Subject: postbank.de / dslbank.de In-Reply-To: <56B09676.7090007@datev.de> References: <56B09676.7090007@datev.de> Message-ID: <20160202115533.GA16410@x2.esmtp.org> On Tue, Feb 02, 2016, Andreas Schulze wrote: > $ dig _25._tcp.mailrelay1.bonn.postbank.de tlsa > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20811 I tried several hosts/dig versions, all return NXDOMAIN, not SERVFAIL. $ dig _25._tcp.mailrelay1.bonn.postbank.de tlsa ; <<>> DiG 9.6-ESV-R11-P1 <<>> _25._tcp.mailrelay1.bonn.postbank.de tlsa ... ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64566 Querying ns1.postbank.de directly returns the same. From georg at riseup.net Tue Feb 2 13:02:36 2016 From: georg at riseup.net (georg at riseup.net) Date: Tue, 2 Feb 2016 13:02:36 +0100 Subject: postbank.de / dslbank.de In-Reply-To: <20160202115533.GA16410@x2.esmtp.org> References: <56B09676.7090007@datev.de> <20160202115533.GA16410@x2.esmtp.org> Message-ID: <20160202120236.GB3490@debian> On 16-02-02 03:55:33, ml+dane-users at esmtp.org wrote: > On Tue, Feb 02, 2016, Andreas Schulze wrote: > > > $ dig _25._tcp.mailrelay1.bonn.postbank.de tlsa > > > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20811 > > I tried several hosts/dig versions, all return NXDOMAIN, not SERVFAIL. ...getting the same (NXDOMAIN) with DiG 9.9.5-9+deb8u5-Debian. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: From mailinglisten+spamtrap at pothe.de Tue Feb 2 13:30:56 2016 From: mailinglisten+spamtrap at pothe.de (Andreas Pothe) Date: Tue, 2 Feb 2016 13:30:56 +0100 Subject: postbank.de / dslbank.de In-Reply-To: <56B09676.7090007@datev.de> References: <56B09676.7090007@datev.de> Message-ID: <56B0A180.2020405@pothe.de> Hi, Am 02.02.2016 um 12:43 schrieb Andreas Schulze: > 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 > > ... > > 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 :-/ Deutsche Postbank has some issues on its DNS servers: http://dnsviz.net/d/postbank.de/dnssec/ http://dnsviz.net/d/dslbank.de/dnssec/ http://dnsviz.net/d/bhw.de/dnssec/ (postbank|dslbank|bhw).de/DNSKEY: The response (512 bytes) was malformed. (62.153.105.1, 62.153.105.2, 195.50.155.127, UDP_0_EDNS0_32768_512) May this cause the reported problems on some systems? In fact I know Deutsche Postbank AG do not promote any TLSA / DANE records for any of its domains. From mailinglisten+spamtrap at pothe.de Tue Feb 2 13:36:50 2016 From: mailinglisten+spamtrap at pothe.de (Andreas Pothe) Date: Tue, 2 Feb 2016 13:36:50 +0100 Subject: postbank.de / dslbank.de In-Reply-To: <56B0A180.2020405@pothe.de> References: <56B09676.7090007@datev.de> <56B0A180.2020405@pothe.de> Message-ID: <56B0A2E2.3040800@pothe.de> Am 02.02.2016 um 13:30 schrieb Andreas Pothe: > Deutsche Postbank has some issues on its DNS servers: > http://dnsviz.net/d/postbank.de/dnssec/ > http://dnsviz.net/d/dslbank.de/dnssec/ > http://dnsviz.net/d/bhw.de/dnssec/ (postbank|dslbank|bhw).de/DNSKEY: > The response (512 bytes) was malformed. (62.153.105.1, 62.153.105.2, > 195.50.155.127, UDP_0_EDNS0_32768_512) May this cause the reported > problems on some systems? In fact I know Deutsche Postbank AG do not > promote any TLSA / DANE records for any of its domains. Oh, dslbank.de has a corrupt DS entry at .de level (DS without corresponding DNSKEY). This can make trouble too, I think. From bjorn at mork.no Tue Feb 2 14:42:02 2016 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 02 Feb 2016 14:42:02 +0100 Subject: postbank.de / dslbank.de In-Reply-To: <56B0A2E2.3040800@pothe.de> (Andreas Pothe's message of "Tue, 2 Feb 2016 13:36:50 +0100") References: <56B09676.7090007@datev.de> <56B0A180.2020405@pothe.de> <56B0A2E2.3040800@pothe.de> Message-ID: <874mdr6xg5.fsf@nemi.mork.no> Andreas Pothe writes: > Oh, dslbank.de has a corrupt DS entry at .de level (DS without > corresponding DNSKEY). This can make trouble too, I think. I don't see that (now at least). There are 4 DS records and 4 ZSKs with matching IDs at least: bjorn at canardo:~$ dig +dnssec ds postbank.de @a.nic.de +multiline ; <<>> DiG 9.9.5-9+deb8u5-Debian <<>> +dnssec ds postbank.de @a.nic.de +multiline ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63458 ;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;postbank.de. IN DS ;; ANSWER SECTION: postbank.de. 86400 IN DS 53214 7 2 ( 0D2B8312AC2E52B9A1B1FD8A8F9824CF6D7545D0A0D5 EFC47AB5C84AF0AB06FC ) postbank.de. 86400 IN DS 41601 7 2 ( 6553D5202663A13E67C3E0E38E457B01DA54B0583D1E 03943D88EEE15DEDF2E3 ) postbank.de. 86400 IN DS 13734 7 2 ( 52392391140DF30BE650BD34073BAC554A420D5657BE 3F00A0B41B8336937C7C ) postbank.de. 86400 IN DS 18276 7 2 ( CF18D83746B799D046A0B7DF751F5EB0A1DB2CD154CE 77BBD44E0CB261CA05C5 ) postbank.de. 86400 IN RRSIG DS 8 2 86400 ( 20160209110000 20160202110000 62490 de. fz+k9OA+O2FHN5JQETlhGd/XuLKVUCXO1rwQ0fqZhqzP JFQStHcSs9tyjLfz8IuCPgiQUphtKtzjT44D0HH5j0FI rNqv/43lpiQtH/EI2Qbfub1SyV9HbO4g71btTvvlT33T Vva7w3WnYKFUeF48kOfJNdK2TArAgftttM7/alM= ) ;; Query time: 45 msec ;; SERVER: 2001:678:2::53#53(2001:678:2::53) ;; WHEN: Tue Feb 02 14:37:16 CET 2016 ;; MSG SIZE rcvd: 394 bjorn at canardo:~$ dig +dnssec dnskey postbank.de @ns1.postbank.de +multiline ; <<>> DiG 9.9.5-9+deb8u5-Debian <<>> +dnssec dnskey postbank.de @ns1.postbank.de +multiline ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22666 ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;postbank.de. IN DNSKEY ;; ANSWER SECTION: postbank.de. 86400 IN DNSKEY 257 3 7 ( AwEAAcRzTe+/LM0moPFfSFK8F5kg+z6EFCzy2RcUUT2E CY12qLab0PqjHqPa/qN3k+FzgJlrZzlkuDwWLJg6Mvco 7JgIHEl3447G2NLUOcpuiHZ9HlId5jvyN2GXOij+C+wB Fhuo54rAG+TT6tXk+B1pH88enxLUH14iihFsKiJdkMkW D2ejskL/upKoRWh0ke/IlfheSnLMppJRouPjxU6TWTko odkFy3xkZFM7C+1fo+HzY6arN7zhj1wSqAikSLoOBZlC N/B+Afx53UMawP00Ftc+xm6pD3VhDp9NjcB1fOdVtUMc +CWTl3kXaoWdPDjesD5PbTiDgDzCCcn+/1e280U= ) ; KSK; alg = NSEC3RSASHA1; key id = 18276 postbank.de. 86400 IN DNSKEY 257 3 7 ( AwEAAbN0sNttYJE7OlzpVif9w5RzZ7Atmc+/pR9Qfh5w C/rBwFuxADYbC6FUhQkpRZT+oXIW7aaSBUjA3QFyMK7f zfM7F3iIqdgDLL2ettHFBTy2Ch2MoTleFtWU26lJ0YPz DLWtHbQdz6KHP5NJR+K6NqlPtn8hH3N88BpLVwITY855 uXFHEPqmAOP9pSpDcs2FHAduJxq6KtBhMLrDasE01dfn xlX2+EpLqD2V7BKrJ7s9/3u2d6YFrmHhkS8HX73yexbz mXo5RVncdn6S55gmFc3q7E0iUUAdZbuAyQfX92lcM+9y e8wHPktQyaKa6obRekZUJr4FNe7+hwESnw+/dXM= ) ; KSK; alg = NSEC3RSASHA1; key id = 13734 postbank.de. 86400 IN DNSKEY 257 3 7 ( AwEAAfAiDH5Os1tmMwBS+p4SczjzYUNCBOX3MZjRcoWl cErrjNWlAVWqimM4bFZB/nRzreVtmHCO3kYfJgazuT3T 2W6Qe6fs4HN8k4ETUTC5taPfmZQ9ReNDD5QfLIk/LIAQ MJ39Y1QAeJrK2/RFQA1LwKPyuehQZWNxsuPoClVFKizQ 2eozAIV1g6JtCyrtsin3288coz/ZAaGDShQQXoMzMfyg rFiZyurtUqf90IWZhI4Gc9rxApdFgrV4t4FeFNk+LGtr ahun1yy2UNtUcpgvRgzG4mw8HG41PYDUCmzvlwNXUmpo Cwt7Oa3Zybu6ikGprfBSM11SZURRSRv8BryCy+k= ) ; KSK; alg = NSEC3RSASHA1; key id = 53214 postbank.de. 86400 IN DNSKEY 257 3 7 ( AwEAAcnx4BAUeeDyAkPIkm9gAXERrFxy9XIDN5EPFQny H/eLjqgmSA2B09sTODO+5loPR1PTsk0RkJabwrPJXUll 6FfRodV/1lW3QltT/7y17698rqGrc7sqyDgxo5vJx+Ta JDjD6IlhWjI6FH8pAFonBgrOJz/nS0sy1oxbubEbGCcY 1W8+l2X6fecHqVR3tvdhdPmCOVzCh5sX6YC/FnisOQ/h 2Pi2kKIiac9iTq/A2Vw0i5dWYWw//ZqeO0TA0WDmXCtK UtvUVurDeTrKx5WiMIYrefLUC77Aa9vjXb6gpzCiJxoo cJCgvXateBayPTrit/fBay24fvqRWWoBvolVIhE= ) ; KSK; alg = NSEC3RSASHA1; key id = 41601 postbank.de. 86400 IN DNSKEY 256 3 7 ( AwEAAbIrv7LW/T9qjAM9p+kkppvH1K3GJhbSS+cNza3B 1r2tRR82Z8PcZclYRqv2aBvjiAPcZv6lOupQcYD/Vrpg MEjrzEbSn85vr0OYYjqHq+/WTT57x9Ko6Y9/vtbIws7x Kq9GigSWhbpTRn9qsSFisI17yn9jVdWsN9bNinOMnzm1 ) ; ZSK; alg = NSEC3RSASHA1; key id = 63284 postbank.de. 86400 IN DNSKEY 256 3 7 ( AwEAAbipCwn6Fbh3kbrGENYu4EGKnkLsh1+9ACGLcDR7 iTysuces2ot9VnGdq+zg0+D3f/IDgSMNU+PPE09bvKfg HqDod+f2TuvBiYLZfjr2sMwrlqQnGvSpXfuc9t071JI7 uz80LnlDR9rtoF+Ni6dSI6Nw8AX10hQTkS4KwqAx/Ftd ) ; ZSK; alg = NSEC3RSASHA1; key id = 48839 postbank.de. 86400 IN DNSKEY 256 3 7 ( AwEAAda3BdXHnv5nGstQ9nECdO5S25sihAMCJbphVJ13 QJ9yw+fsfOZHaFMX3Oi3uTkwtobOZGizeuUF8SsQRpY6 wXEP1Aa4HMgm0coCcGbGHjkE86pvmDDh9PExpmg71VvW lQZubucLoGRj6ZAr64UeNofci9J1sTo1Ub6WAoKXANIT ) ; ZSK; alg = NSEC3RSASHA1; key id = 13394 postbank.de. 86400 IN DNSKEY 256 3 7 ( AwEAAahHOOnai3XHpvSa2fKArbATWwHQA4+xeUitroui 7i+l+Exy5Q3pQ0AASRo2k6iYWXGCpklLO0mKryjCpFUN VuIdyVC+fSZlgOPpdRgzwjv9w3C7EBafTl0bVit0TNHS WzFfzy/0rSr4Bpkg2YrfGy38WqDwHmcOUG86HfugBedp ) ; ZSK; alg = NSEC3RSASHA1; key id = 43898 postbank.de. 86400 IN RRSIG DNSKEY 7 2 86400 ( 20160208145154 20160201145154 53214 postbank.de. hgawwvu2Ne5583qitm7cnXtDI2fx8ZAskZfJ+B7dBe9T K24imxqC8DC98y5+QcVFKEv0KW8qxNSitlIJt8CrjgMH C6TPj8O9RMG/ro0jou2GpQMANJjcmszwpGCWVsT2h90P pR3jPb0+6S24ee/0Z+dVj94iCi5D51WOwxQJGVCIqRj0 7cOtfcKo2XGIqQWw8pnPaeOUA9yn0VPG3P4dHAqbRuEI Uj6rD4qh5FEwaIZJU3oqR05/Q+h7utoKsAM9HO3uzUfY U0n+IYfG+ZYixQaw8jxP3kmgo73skIIHgIfZjTRltzhb CACU/qcwPCayLAjlBp98xzIpWCgM7ho4kQ== ) postbank.de. 86400 IN RRSIG DNSKEY 7 2 86400 ( 20160208145154 20160201145154 41601 postbank.de. hKsw+kmm3JqYblS2dNOVGpfe5SzNViRs8XBTPznTst5Q Vj6VGdWmTB0RdeOby/WF1e5l/MsV1Z9lwD4VL1gVmWnm dqTVYJMamep/FI1yRxEY6PPkdryr3KBDyNTWPBALnRpm IFSmg7et8l3MWqAZk80RSfiNZ8UhDJjXgzJP3gE6C8JD nTwsLx7DGu2Lnd0gRv/I8CCEr0Mlyv3QPZR+Qii2J2jO t3/au2vyYZ2hRnaZfAB/PL1reISUkcIPiCfwshXGkA4b fEunkTZIy5hegC6olhzx4wdmpWg1CZudltNfqBxp3dZh dIBHlFQiZFfZYVz1Eb5I9Y44LogZfRMblg== ) postbank.de. 86400 IN RRSIG DNSKEY 7 2 86400 ( 20160208145154 20160201145154 13394 postbank.de. z/a7WjxUUZrRvG0MhqaTsAowKoYitadMDYxaFc3c3qhj x8a67ihz55MwRLiD6TgBPDUd8cpWyCTNzJne8vhoAAIK bVaL5ide8NCqDLljbq9+qHVp+oWUr21Q2VcUwSUie3KR 6/WF+LqfeTw2bXnTjVu2SY0Ms4HNDvQsQpoK81Y= ) postbank.de. 86400 IN RRSIG DNSKEY 7 2 86400 ( 20160208145154 20160201145154 43898 postbank.de. F4TUFHteWlIpCf682c8Ymd5ZK7q9XQs+vekUNoB36fUL yPLElMUh1hOrsS3hJ4gTUyDkoa0o3R0p5fh/6URdRpeW RdP6PwqFvFpkU+pXSRHFdteoLBZmQQTv7ajeTPJJo4L7 43Z6LSbK3El2VCeu9p9IuUJqw2tafjjOOvi3TRM= ) ;; Query time: 48 msec ;; SERVER: 62.153.105.1#53(62.153.105.1) ;; WHEN: Tue Feb 02 14:37:26 CET 2016 ;; MSG SIZE rcvd: 2808 But publishing no less than 8 keys, resulting in a 2808 reply, is more than risky IMHO. Especially in the bank business. You only need one paranoid firewall to break that. Why would anyone need to publish 4 ZSKs *and* 4 KSKs? Bj?rn From me at junc.eu Tue Feb 2 18:14:43 2016 From: me at junc.eu (Benny Pedersen) Date: Tue, 02 Feb 2016 18:14:43 +0100 Subject: postbank.de / dslbank.de In-Reply-To: <56B09676.7090007@datev.de> References: <56B09676.7090007@datev.de> Message-ID: On 2016-02-02 12:43, Andreas Schulze wrote: > $ postconf smtp_tls_security_level > smtp_tls_security_level = dane http://blog.weetech.co/2014/11/implementing-dnssec-and-dane-for-email.html postconf -e "smtp_dns_support_level = dnssec" postconf -e "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 why serv fail here ? enable lame logs in bind9 i dont use unbound From m at tthias.eu Tue Feb 2 18:37:27 2016 From: m at tthias.eu (Matthias Wimmer) Date: Tue, 2 Feb 2016 17:37:27 +0000 Subject: postbank.de / dslbank.de In-Reply-To: References: <56B09676.7090007@datev.de> Message-ID: <20160202173726.GA8733@jade.amessage.eu> Hi Benny, El 2016-02-02 18:14:43, Benny Pedersen escribi?: > >$ postconf smtp_tls_security_level > >smtp_tls_security_level = dane > > http://blog.weetech.co/2014/11/implementing-dnssec-and-dane-for-email.html > > postconf -e "smtp_dns_support_level = dnssec" > postconf -e "smtp_tls_security_level = dane" The SERVFAIL is not generated by your postfix, these settings should not cause it. > >$ dig _25._tcp.mailrelay1.bonn.postbank.de tlsa > > > >... > >;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20811 > >;_25._tcp.mailrelay1.bonn.postbank.de. IN TLSA > > why serv fail here ? > > enable lame logs in bind9 > > i dont use unbound Interesting question. Tried it locally ... On the first two or three requests I got SERVFAIL as well. Some requests later (i.e. within the same minute) I could not reproduce these problems. It also did not matter which of the three published nameserver of postbank.de I was querying, all were fine after the first requests. Anyway to reproduce the queries postfix sends I normally would add the +dnssec option to the dig command. BTW: DNSsec resolving on this host is working without problems in general. Regards, Matthias -- Matthias Wimmer Contact details: http://matthias.wimmer.tel/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From andreas.schulze at datev.de Wed Feb 3 07:26:00 2016 From: andreas.schulze at datev.de (Andreas Schulze) Date: Wed, 3 Feb 2016 07:26:00 +0100 Subject: SOLVED: postbank.de / dslbank.de In-Reply-To: References: <56B09676.7090007@datev.de> Message-ID: <56B19D78.5060504@datev.de> Am 02.02.2016 um 18:14 schrieb Benny Pedersen: >> $ dig _25._tcp.mailrelay1.bonn.postbank.de tlsa >> >> ... >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20811 >> ;_25._tcp.mailrelay1.bonn.postbank.de. IN TLSA > > why serv fail here ? > > i dont use unbound a feature in unbound called "0x20 capitalisation" was the reason we now add an exeption to unbound and get also NXDOMAIN see https://unbound.net/pipermail/unbound-users/2016-February/004192.html unbound.conf: server: caps-whitelist: postbank.de (require unbound-1.5.4 or newer) -- A. Schulze DATEV eG From ietf-dane at dukhovni.org Wed Feb 3 09:06:04 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 3 Feb 2016 08:06:04 +0000 Subject: Small uptick in domains with long-term incorrect TLSA records Message-ID: <20160203080604.GH19242@mournblade.imrryr.org> 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-records-with-le-certificates/70+22 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. From me at junc.eu Wed Feb 3 17:04:31 2016 From: me at junc.eu (Benny Pedersen) Date: Wed, 03 Feb 2016 17:04:31 +0100 Subject: SOLVED: postbank.de / dslbank.de In-Reply-To: <56B19D78.5060504@datev.de> References: <56B09676.7090007@datev.de> <56B19D78.5060504@datev.de> Message-ID: <3caac694d27280c1f0b495a10706d677@junc.eu> On 2016-02-03 07:26, Andreas Schulze wrote: >> i dont use unbound > > a feature in unbound called "" was the reason > we now add an exeption to unbound and get also NXDOMAIN > see > https://unbound.net/pipermail/unbound-users/2016-February/004192.html > > unbound.conf: > server: caps-whitelist: postbank.de > > (require unbound-1.5.4 or newer) another reason for not using unbound ? another fun story http://serverfault.com/questions/464143/dns-requests-for-odd-domain-names-like-mail-mydomain-de hope that bind10 will not begin all that funny stories posttls-finger dslbank.de have never giving warning here, just untrusted tls is this solved now ? From ietf-dane at dukhovni.org Wed Feb 3 18:14:43 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 3 Feb 2016 17:14:43 +0000 Subject: Small uptick in domains with long-term incorrect TLSA records In-Reply-To: <20160203080604.GH19242@mournblade.imrryr.org> References: <20160203080604.GH19242@mournblade.imrryr.org> Message-ID: <20160203171443.GL19242@mournblade.imrryr.org> On Wed, Feb 03, 2016 at 08:06:04AM +0000, Viktor Dukhovni wrote: > I am now tracking 25 broken domains that show no sign that they > are likely to be fixed soon: > > ... > neuhaus-city.de > ... It was brought to my attention that this domain had valid TLSA records and I missed the change in state. The other 24 still have problems. The number of recent additions has dropped from 11 to 8 as 3 have resolved their issues. -- Viktor. From bjorn at mork.no Wed Feb 3 18:33:57 2016 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 03 Feb 2016 18:33:57 +0100 Subject: SOLVED: postbank.de / dslbank.de In-Reply-To: <3caac694d27280c1f0b495a10706d677@junc.eu> (Benny Pedersen's message of "Wed, 03 Feb 2016 17:04:31 +0100") References: <56B09676.7090007@datev.de> <56B19D78.5060504@datev.de> <3caac694d27280c1f0b495a10706d677@junc.eu> Message-ID: <87y4b14s1m.fsf@nemi.mork.no> Benny Pedersen writes: > On 2016-02-03 07:26, Andreas Schulze wrote: > >>> i dont use unbound >> >> a feature in unbound called "" was the reason >> we now add an exeption to unbound and get also NXDOMAIN >> see >> https://unbound.net/pipermail/unbound-users/2016-February/004192.html >> >> unbound.conf: >> server: caps-whitelist: postbank.de >> >> (require unbound-1.5.4 or newer) > > another reason for not using unbound ? The bug in the postbank.de servers will cause SERVFAIL with *any* DNSSEC validator unless you are careful to keep the query lower case only. You can easily verify this yourself. Simply query your validating resolver for a non-existing name in postbank.de, capitalizing one or ore characters in the query: bjorn at nemi:~$ dig ns5.Postbank.de ; <<>> DiG 9.9.5-9+deb8u5-Debian <<>> ns5.Postbank.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48848 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ns5.Postbank.de. IN A ;; Query time: 1278 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 03 18:27:13 CET 2016 ;; MSG SIZE rcvd: 44 No unbound involved here: bjorn at nemi:~$ dig version.bind txt chaos ; <<>> DiG 9.9.5-9+deb8u5-Debian <<>> version.bind txt chaos ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44913 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;version.bind. CH TXT ;; ANSWER SECTION: version.bind. 0 CH TXT "9.9.5-9+deb8u5-Debian" ;; AUTHORITY SECTION: version.bind. 0 CH NS version.bind. ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 03 18:29:22 CET 2016 ;; MSG SIZE rcvd: 89 Bj?rn From ietf-dane at dukhovni.org Mon Feb 8 03:39:52 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 7 Feb 2016 21:39:52 -0500 Subject: New tools in Postfix 3.1-20160207 Message-ID: <13348D08-8330-4DD6-84F0-3F074D26711E@dukhovni.org> 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. From teddyap at protonmail.ch Wed Feb 17 08:25:10 2016 From: teddyap at protonmail.ch (TAP-{R&D}) Date: Wed, 17 Feb 2016 02:25:10 -0500 Subject: New tools in Postfix 3.1-20160207 In-Reply-To: <13348D08-8330-4DD6-84F0-3F074D26711E@dukhovni.org> References: <13348D08-8330-4DD6-84F0-3F074D26711E@dukhovni.org> Message-ID: <_9WEx50uECaD9ldWaKUcyMbFmut6KjYRVbuKX2DHm5J0gUo1mXUSSz_gZNi6Kaznr_9LycsKN5Au4vVhf3cbmw==@protonmail.ch> Dear Colleagues, Thanks for all information. fyi, currently we are still in progress for pandi.id security development initial stage.as .id registry. Cheers, /tap Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland. -------- Original Message -------- Subject: New tools in Postfix 3.1-20160207 Local Time: February 8, 2016 9:39 am UTC Time: February 8, 2016 2:39 AM From: ietf-dane at dukhovni.org To: dane-users at sys4.de 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Mon Feb 29 21:30:37 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 29 Feb 2016 20:30:37 +0000 Subject: Small uptick in domains with long-term incorrect TLSA records Message-ID: <20160229203037.GR12869@mournblade.imrryr.org> 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.