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
Hey.
Am 19.01.2015 12:15, schrieb Wolfgang Breyha:
One of our users tried to send mail to the domain education.lu. [...] 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?
Postfix (2.11.2) seems to be able to talk to education.lu just fine:
posttls-finger: using DANE RR: _25._tcp.smtpgate2.restena.lu IN TLSA 1 0 2 75:12:52:FD:4B:22:7D:40:A0:FA:D1:D3:AB:3D:4B:67:49:49:D8:4E:8B:B9:9B:08:14:CC:08:27:5F:66:6C:1C:9C:92:67:B6:F5:F6:86:EA:D2:19:39:B8:1F:1E:2B:90:CE:7C:24:06:F3:2E:70:E0:BD:1D:44:BC:B6:10:00:4E posttls-finger: Connected to smtpgate2.restena.lu[158.64.1.59]:25 posttls-finger: < 220 smtpgate2.restena.lu ESMTP posttls-finger: > EHLO metis.tribut.de posttls-finger: < 250-smtpgate2.restena.lu posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 29622272 posttls-finger: < 250-STARTTLS posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250 8BITMIME posttls-finger: > STARTTLS posttls-finger: < 220 2.0.0 Ready to start TLS posttls-finger: smtpgate2.restena.lu[158.64.1.59]:25: depth=0 matched end entity certificate sha512 digest 75:12:52:FD:4B:22:7D:40:A0:FA:D1:D3:AB:3D:4B:67:49:49:D8:4E:8B:B9:9B:08:14:CC:08:27:5F:66:6C:1C:9C:92:67:B6:F5:F6:86:EA:D2:19:39:B8:1F:1E:2B:90:CE:7C:24:06:F3:2E:70:E0:BD:1D:44:BC:B6:10:00:4E posttls-finger: smtpgate2.restena.lu[158.64.1.59]:25: Matched subjectAltName: *.restena.lu posttls-finger: smtpgate2.restena.lu[158.64.1.59]:25: subjectAltName: restena.lu posttls-finger: smtpgate2.restena.lu[158.64.1.59]:25 CommonName *.restena.lu posttls-finger: smtpgate2.restena.lu[158.64.1.59]:25: subject_CN=*.restena.lu, issuer_CN=GlobalSign Organization Validation CA - SHA256 - G2, fingerprint=ED:82:8A:81:32:90:E5:1F:94:39:15:5D:49:DE:2A:5A:40:5B:1F:51, pkey_fingerprint=2A:D8:19:E7:7E:C3:5D:06:4D:5E:5C:D9:49:D3:25:2F:31:82:43:D3 posttls-finger: Verified TLS connection established to smtpgate2.restena.lu[158.64.1.59]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) posttls-finger: > EHLO metis.tribut.de posttls-finger: < 250-smtpgate2.restena.lu posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 29622272 posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250 8BITMIME posttls-finger: > QUIT posttls-finger: < 221 2.0.0 Bye
Regards felix
On 19/01/15 12:26, Felix Eckhofer wrote:
Hey.
Am 19.01.2015 12:15, schrieb Wolfgang Breyha:
One of our users tried to send mail to the domain education.lu. [...] 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?
Postfix (2.11.2) seems to be able to talk to education.lu just fine:
Postfix doesn't honor 3.1.3 of the latest DANE-SMTP draft then?
"...SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0) or PKIX-EE(1) is undefined. SMTP clients should generally treat such TLSA records as unusable."
Greetings, Wolfgang
Hey.
Am 19.01.2015 12:49, schrieb Wolfgang Breyha:
Postfix doesn't honor 3.1.3 of the latest DANE-SMTP draft then?
It appears not to.
"...SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0) or PKIX-EE(1) is undefined. SMTP clients should generally treat such TLSA records as unusable."
Note that it says client treatment is undefined. It also says "should", not "SHOULD". However, I don't think the connection should fail one way or the other (the certificate appears to be signed by a proper CA even). See dane-smtp 2.2.
felix
On 19/01/15 13:21, Felix Eckhofer wrote:
Note that it says client treatment is undefined. It also says "should", not "SHOULD".
And that makes which difference? ;-)
However, I don't think the connection should fail one way or the other (the certificate appears to be signed by a proper CA even). See dane-smtp 2.2.
I think the TLSA RR should not (or SHOULD NOT?) be used for DANE, but on the other hand the TLS connection should not fail since there is no "usable" TLSA record at all in respect to DANE-SMTP. Right?
Greetings, Wolfgang
Hey.
Am 19.01.2015 13:39, schrieb Wolfgang Breyha:
On 19/01/15 13:21, Felix Eckhofer wrote:
Note that it says client treatment is undefined. It also says "should", not "SHOULD".
And that makes which difference? ;-)
If treatment is undefined, postfix is compliant with the dane-smtp draft no matter what it does. As for "SHOULD", see RFC 2119.
I think the TLSA RR should not (or SHOULD NOT?) be used for DANE, but on the other hand the TLS connection should not fail since there is no "usable" TLSA record at all in respect to DANE-SMTP. Right?
That is how I understand it, yes. A PKIX-EE RR "SHOULD NOT" be published (as per 3.1.3). The behavior of the smtp client is undefined, as you quoted yourself, but if they choose to treat them as unusable a connection "MUST be made via TLS" (2.2).
felix
"WB" == Wolfgang Breyha wbreyha@gmx.net writes:
WB> The DANE validator WB> https://dane.sys4.de/smtp/education.lu WB> says: "Unusable TLSA Records". Most likely because it is type 1 not allowed WB> for DANE-SMTP?
There is little reason not to accept the distribution-provided /etc/ssl/certs certificates when sending mail.
If you add those to your exim config then mail will send.
The postfix config string to do that is:
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
For exim it looks like the config is named:
tls_verify_certificates
If you set that to /etc/ssl/certs/ca-certificates.crt exim will verify and accept tls for destinations like education.lu's mx servers.
-JimC
On Mon, Jan 19, 2015 at 12:15:34PM +0100, Wolfgang Breyha wrote:
One of our users tried to send mail to the domain education.lu.
This is one of four related .lu domains with "unusable" TLSA RRsets. I've notified them of the problem multiple times, and they initially (on Dec 10th 2014) said they'd take care of it, but nothing has happened.
dns.lu education.lu lmrl.lu restena.lu
There are just six more that I know of for a total of 10, in contrast to 962 domains with conformant certificate usages.
dougbarton.us retrosnub.uk retrosnub.net retrosnub.co.uk dnmailer.de davidhogue.com
The first is a conscientious objector to the SMTP draft's certificate usage restrictions. The others never replied to my email notifying them of the problem.
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?
Correct, this certificate usage is not appropriate for DANE SMTP and should be treated as unusable by DANE SMTP clients. The Postfix implementation predates the draft's final language.
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?
Todd Lyons unfortunately ran out of cycles before we finished the Exim DANE code review.
That's a bug in the Exim implementation. When all TLSA records are "unusable", the client MUST use TLS but without DANE authentication, using either no authentication, or whatever authentication mechanisms are appropriate via local policy.
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-2.2
A secure non-empty TLSA RRset where all the records are unusable: A connection to the MTA MUST be made via TLS, but authentication is not required. Failure to establish an encrypted TLS connection MUST result in falling back to the next SMTP server or delayed delivery.
http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-10.3
A service with DNSSEC-validated TLSA records implicitly promises TLS support. When all the TLSA records for a service are found "unusable", due to unsupported parameter combinations or malformed associated data, DANE clients cannot authenticate the service certificate chain. When authenticated TLS is dictated by the application, the client SHOULD NOT connect to the associated server. If, on the other hand, the use of TLS is "opportunistic", then the client SHOULD generally use the server via an unauthenticated TLS connection, but if TLS encryption cannot be established, the client MUST NOT use the server. Standards for DANE specific to the particular application protocol may modify the above requirements, as appropriate, to specify whether the connection should be established anyway without relying on TLS security, with only encryption but not authentication, or whether to refuse to connect entirely. Application protocols need to specify when to prioritize security over the ability to connect under adverse conditions.
On Mon, Jan 19, 2015 at 11:33:36AM -0500, James Cloos wrote:
WB> The DANE validator WB> https://dane.sys4.de/smtp/education.lu WB> says: "Unusable TLSA Records". Most likely because it is type 1 not allowed WB> for DANE-SMTP?
There is little reason not to accept the distribution-provided /etc/ssl/certs certificates when sending mail.
Postfix will not use any "distribution provided" Web PKI CAs when doing DANE authentication. In particular it maps usage PKIX-EE(1) to DANE-EE(3).
The postfix config string to do that is:
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
This is not useful. Neither "may" nor "dane" make any use of such certificates, they just slow down smpt(8) process startup.
These are used for "secure", but that's for designated destinations, and should generally be much more selective about which CAs to trust in that context.
On 19/01/15 16:41, Viktor Dukhovni wrote:
That's a bug in the Exim implementation. When all TLSA records are "unusable", the client MUST use TLS but without DANE authentication, using either no authentication, or whatever authentication mechanisms are appropriate via local policy.
An Exim fix is in test.
"VD" == Viktor Dukhovni ietf-dane@dukhovni.org writes:
VD> Postfix will not use any "distribution provided" Web PKI CAs when VD> doing DANE authentication. In particular it maps usage PKIX-EE(1) VD> to DANE-EE(3).
Perhaps not, but one still gets Trusted in the logs when sending to sites like goog where each mx has a ca-signed cert.
VD> This is not useful. Neither "may" nor "dane" make any use of such VD> certificates, they just slow down smpt(8) process startup.
Not every destination has tlsa.
VD> These are used for "secure", but that's for designated destinations, VD> and should generally be much more selective about which CAs to VD> trust in that context.
It is a step up from Untrusted.
I do, of course, still prefer that all destinations support dane.
But until then....
-JimC
On Mon, Jan 19, 2015 at 04:41:42PM +0000, Viktor Dukhovni wrote:
There are just six more that I know of for a total of 10, in contrast to 962 domains with conformant certificate usages.
Just to update the statistics, that's 971 conformant domains as of this morning. In addition 6 domains with TLSA records that don't match reality. Mail to these domains MUST fail:
webseitendesigner.com webseitenserver.com xworks.net joworld.net hasno.info castleturing.net
Finally, there are DNSSEC hosting providers whose nameservers don't implement denial of existence correctly. Their NODATA or NXDOMAIN responses for "_25._tcp.<mxhost> IN TLSA ?" are "bogus". When they also don't have a working backup MX, mail to such domains is expected to fail.
This applies to 1507 domains in my survey (which found ~28000 DNSSEC enabled domains some of whose MX hosts also lie in signed zones).
Only 7 of the problem domains are large enough to appear as sending or receiving email domains in Google's email transparency report:
belgievacature.be walmart.com.br disa.mil nederlandvacature.nl prorun-mail.nl patriotguard.org sourceware.org
Out of the 1496 domains, 1420 are managed by the top 10 (by count of non-working domains) providers:
871 forpsi.com/forpsi.net 467 hostnet.nl 27 transip.nl/ns0.nl 16 interstroom.nl 10 grdns.cz 8 binero.se 7 metaregistrar.nl 5 openprovider.eu 5 active24.cz 4 thosting.cz
The remaining 27 "transip" domains will likely be fixed in a matter of days. Transip are making good progress, and have already fixed ~1000 previously problematic domains. The .nl and .cz registries are aware of the hostnet.nl and forpsi.cz issues, and I believe that these are slated to be fixed near term.
That would leave just 1496 - 1338 = 158 small domains with nameserver issues, many of which are likely parked or only used for HTTP, and are unlikely to be seen by anyone not specifically looking for problem domains.
Fixing this "long tail" of the distribution will take more time, but most DANE senders are unlikely to run into any issues.
If you do run into a domain to which you're sending email, but delivery consistently fails because TLSA record lookups SERVFAIL or time out, check the problem domain at https://dane.sys4.de, and the specific TLSA RRset at dnsviz.net. These should confirm whether the problem is on your end or not. For example, see the litany of woes for "sourceware.org":
http://dnsviz.net/d/_25._tcp.sourceware.org/dnssec/
or the more mundane (looks like an out of date PowerDNS, an upgrade to 3.3.1 or later should fix it) denial of existence problem at the MX host for "belgievacature.be":
http://dnsviz.net/d/_25._tcp.mail.nrdbv.nl/dnssec/
If the problem is confirmed, please notify the administrative contact of the other domain (send a notice from Gmail or similar, or temporarily disable DANE for that domain, ...). Let them know their DNSSEC implementation has problems. They may need to upgrade PowerDNS, replace or patch djbdns, or fix firewall configurations that drop TLSA queries.
On Mon, Jan 19, 2015 at 04:41:42PM +0000, Viktor Dukhovni wrote:
On Mon, Jan 19, 2015 at 12:15:34PM +0100, Wolfgang Breyha wrote:
One of our users tried to send mail to the domain education.lu.
This is one of four related .lu domains with "unusable" TLSA RRsets. I've notified them of the problem multiple times, and they initially (on Dec 10th 2014) said they'd take care of it, but nothing has happened.
dns.lu education.lu lmrl.lu restena.lu
For the record, all four got fixed today. Thanks go to the staff at restena.lu. That leaves just 6 more PKIX-EE(1) holdouts to go.
And the number of validated domains goes up to 976 (though 89 of them have backup MX hosts without TLSA records, and so are not yet completely protected).
On Mon, Jan 19, 2015 at 07:01:15PM +0000, Viktor Dukhovni wrote:
Out of the 1496 domains, 1420 are managed by the top 10 (by count of non-working domains) providers:
871 forpsi.com/forpsi.net 467 hostnet.nl 27 transip.nl/ns0.nl 16 interstroom.nl 10 grdns.cz 8 binero.se 7 metaregistrar.nl 5 openprovider.eu 5 active24.cz 4 thosting.cz
The remaining 27 "transip" domains will likely be fixed in a matter of days. Transip are making good progress, and have already fixed ~1000 previously problematic domains. The .nl and .cz registries are aware of the hostnet.nl and forpsi.cz issues, and I believe that these are slated to be fixed near term.
I am pleased to report that transip.nl/ns0.nl have fixed all the remaining problem domains on my list. If any remain to be fixed that I did not manage to find, they should be fixed shortly.
I also believe they are also adding support for their hosted customers to publish TLSA and SSHFP records. Thank you transip!
I'll keep this list in the loop on any further major developments.
On Tue, Jan 20, 2015 at 05:39:22PM +0000, Viktor Dukhovni wrote:
I am pleased to report that transip.nl/ns0.nl have fixed all the remaining problem domains on my list. If any remain to be fixed that I did not manage to find, they should be fixed shortly.
I am now pleased to report that forpsi.cz have fixed all but two of their domains (corner case not addressed by main fix). With any luck hostnet.nl will follow relatively soon.
The top 9 problem DNS hosting providers are now:
481 hostnet.nl 121 citynetwork.se 17 interstroom.nl 10 grdns.cz 10 binero.se 6 metaregistrar.nl 6 swedenmail.com 5 openprovider.eu 4 thosting.cz
these account for 660 out of 749 total domains with TLSA record lookup issues. The last 89 domains are part of the long tail that'll have to fixed by their respective owners (many may well be parked or not in any case not used for email).
We finally have more DANE enabled domains (1007 at last count) than broken domains (749). I expect that soon the broken domain count will be pratically insignificant.
At hostnet.nl, the nameserver mishandles denial of existence, have not heard directly from them, but the .NL registry is I believe working with them on remediation.
At citynetwork.se, a firewall drops IPv4 UDP TLSA queries, while allowing the same queries via IPv4 TCP or IPv6 UDP and TCP. There's an open ticket for the citynetwork.se issue, but progress has been very slow. If anyone on this list is a customer of citynetwork, please encourage them to address ticket #AJP-503-19284.
On Mon, Jan 26, 2015 at 09:53:12PM +0000, Viktor Dukhovni wrote:
I am now pleased to report that forpsi.cz have fixed all but two of their domains (corner case not addressed by main fix). With any luck hostnet.nl will follow relatively soon.
The top 9 problem DNS hosting providers are now:
481 hostnet.nl 121 citynetwork.se 17 interstroom.nl 10 grdns.cz 10 binero.se 6 metaregistrar.nl 6 swedenmail.com 5 openprovider.eu 4 thosting.cz
It looks like interstroom.nl are done too.
On Thu, Jan 29, 2015 at 11:42:35PM +0000, Viktor Dukhovni wrote:
On Mon, Jan 26, 2015 at 09:53:12PM +0000, Viktor Dukhovni wrote:
I am now pleased to report that forpsi.cz have fixed all but two of their domains (corner case not addressed by main fix). With any luck hostnet.nl will follow relatively soon.
The top 9 problem DNS hosting providers are now:
481 hostnet.nl 121 citynetwork.se 17 interstroom.nl 10 grdns.cz 10 binero.se 6 metaregistrar.nl 6 swedenmail.com 5 openprovider.eu 4 thosting.cz
It looks like interstroom.nl are done too.
And now hostnet.nl are also done. This leaves just 203 known broken domains, with only the below 11 providers with with more than one broken domain:
121 citynetwork.se 11 grdns.cz 10 binero.se 7 metaregistrar.nl 6 swedenmail.com 4 dnscluster.nl 4 openprovider.eu 2 pretecno.it 2 papaki.gr 2 kniestdns.nl 2 forpsi.net
I am hoping for some good news from citynetwork.se in the not too distant future. At which point I am basically ready to declare victory. The residual problems are essentially noise by comparison with the 1047 DANE-enabled domains, and ~30,000 domains with DNSSEC MX records and MX hosts in signed zones that are neither DANE-enabled (no TLSA records) nor broken.
On Mon, Feb 02, 2015 at 09:01:07PM +0000, Viktor Dukhovni wrote:
And now hostnet.nl are also done. This leaves just 203 known broken domains, with only the below 11 providers with with more than one broken domain:
121 citynetwork.se 11 grdns.cz 10 binero.se 7 metaregistrar.nl 6 swedenmail.com 4 dnscluster.nl 4 openprovider.eu 2 pretecno.it 2 papaki.gr 2 kniestdns.nl 2 forpsi.net
As of today openprovider.eu seems to be resolved, leaving a top 10 list with:
121 citynetwork.se 10 grdns.cz 10 binero.se 7 metaregistrar.nl 6 swedenmail.com 5 dnscluster.nl 2 pretecno.it 2 papaki.gr 2 kniestdns.nl 2 forpsi.net
On Wed, Feb 04, 2015 at 09:12:03PM +0000, Viktor Dukhovni wrote:
As of today openprovider.eu seems to be resolved, leaving a top 10 list with:
121 citynetwork.se 10 grdns.cz 10 binero.se 7 metaregistrar.nl 6 swedenmail.com 5 dnscluster.nl 2 pretecno.it 2 papaki.gr 2 kniestdns.nl 2 forpsi.net
I am finally thrilled to announce that citynetwork.se are also done. A firewall was filtering out DNS queries with RRtypes it does not know about. Don't let your firewalls do this:
http://tools.ietf.org/html/draft-andrews-dns-no-response-issue-06#section-2....
The known broken domain count is now 87, and the top 9 list (47 domains total) is now:
10 registry@binero.se 10 admin@grdns.cz 7 beheer@metaregistrar.nl 6 alex@swedenmail.com 5 hostmaster@dnscluster.nl 3 hostmaster@papaki.gr 2 hostmaster@pretecno.it 2 hostmaster@kniestdns.nl 2 admin@forpsi.net
It is now reasonably "safe" to enable outbound DANE verification. While a few folks are still struggling to keep their DNSSEC zones signed correctly, and some others occasionally neglect to update TLSA records before installing new certificates, the problem volume is now rather low by comparison with the 1050+ domains that work.
https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1 https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.4 https://tools.ietf.org/html/rfc6781
We'll try to add more features to https://dane.sys4.de/ to help domain owners not get into trouble, to stay out of trouble, and get out of trouble quickly if/when they make mistakes. Stay tuned.
Zitat von Viktor Dukhovni ietf-dane@dukhovni.org:
On Wed, Feb 04, 2015 at 09:12:03PM +0000, Viktor Dukhovni wrote:
As of today openprovider.eu seems to be resolved, leaving a top 10 list with:
121 citynetwork.se 10 grdns.cz 10 binero.se 7 metaregistrar.nl 6 swedenmail.com 5 dnscluster.nl 2 pretecno.it 2 papaki.gr 2 kniestdns.nl 2 forpsi.netI am finally thrilled to announce that citynetwork.se are also done. A firewall was filtering out DNS queries with RRtypes it does not know about. Don't let your firewalls do this:
http://tools.ietf.org/html/draft-andrews-dns-no-response-issue-06#section-2....
The known broken domain count is now 87, and the top 9 list (47 domains total) is now:
10 registry@binero.se 10 admin@grdns.cz 7 beheer@metaregistrar.nl 6 alex@swedenmail.com 5 hostmaster@dnscluster.nl 3 hostmaster@papaki.gr 2 hostmaster@pretecno.it 2 hostmaster@kniestdns.nl 2 admin@forpsi.net
It is now reasonably "safe" to enable outbound DANE verification. While a few folks are still struggling to keep their DNSSEC zones signed correctly, and some others occasionally neglect to update TLSA records before installing new certificates, the problem volume is now rather low by comparison with the 1050+ domains that work.
Is there a list of some sort with the already known TLSA secured domains? Would be nice to see the pace of acceptance for different TLDs and so on.
Regards
Andreas
On Thu, Feb 05, 2015 at 09:38:38AM +0100, lst_hoe02@kwsoft.de wrote:
Is there a list of some sort with the already known TLSA secured domains?
I don't feel at liberty to publish the domain list.
Would be nice to see the pace of acceptance for different TLDs and so on.
However, the top TLDs out of the 1059 domains I've curated are:
327 de 159 net 124 com 99 org 44 eu 31 ch 30 nl 20 dk 20 cz 17 uk 13 me 13 at 12 fr 11 info 11 fi 10 io 10 email 9 se 9 be 7 us -------- 976 TOTAL
The remaining 83 domains are scattered across 47 TLDs. If we look instead at domains that are DNSSEC signed and at least one of their "best" MX hosts also lies in a secure zone, but that may not have published DANE TLSA records, the top 20 breakdown becomes:
11083 nl 6402 cz 2966 com 2131 br 1286 net 996 se 961 fr 882 eu 629 de 626 org 358 gov 326 be 174 no 159 pl 146 pt 138 edu 114 ch 112 dk 105 uk 104 ovh ----------- 29698 TOTAL
The remaining ~1000 domains are scattered across 92 TLDs.
Note, that many of the .net/.com/.org/.eu DANE for SMTP domains are actually registered by German domain owners. DANE for SMTP is still very much a .DE phenomenon. It would be good to see more progress elsewhere.
This may take some "evangelists" outside Germany who can write blogs, tutorials, inform the technology press, ... Perhaps once the SMTP DANE draft becomes an RFC (~2-4 months I think), the time will be ripe to start a broader "marketing effort".
The known broken domain count is now 79, and the top 7 list (38 domains total) is now:
10 binero.se 10 grdns.cz 7 metaregistrar.nl 5 dnscluster.nl 2 pretecno.it 2 kniestdns.nl 2 forpsi.net
The remaining 41 problem domains are "singletons", thus likely self-hosted.
Hi Viktor!
I just want to reach out to you and thank you for all your efforts around DANE, helping out all those people who got something wrong and making the Internet a safer place.
Thanks! Raoul
Today grdns.cz fixed their 10 domains. The known broken domain count is now 74, and the top 8 list (30 domains total) is now:
10 registry@binero.se 5 hostmaster@dnscluster.nl 4 hostmaster@thosting.cz 3 beheer@metaregistrar.nl 2 hostmaster@pretecno.it 2 hostmaster@kniestdns.nl 2 dns@aerohosting.cz 2 admin@forpsi.net
The remaining 44 problem domains are "singletons", thus likely self-hosted. For some of the domains the problems are only seen with a subset of the nameservers, so they mostly work.
I may post once more on this topic when binero.se fix their DNS. After that, the long tail is noise we can largely ignore.
Ideally the numbers will continue to gradually shrink, but they are low enough to not warrant further individual attention unless perhaps some of the problem nameservers deploy a lot more DNSSEC-enabled domains. With a bit of luck they'll fix their software or firewalls before they do that.
On Wed, Mar 18, 2015 at 09:15:46AM +0000, Viktor Dukhovni wrote:
Today grdns.cz fixed their 10 domains. The known broken domain count is now 74, and the top 8 list (30 domains total) is now:
10 registry@binero.se ...
The binero.se domains are now practically, fixed. I say "practically", because one of the nameserver clusters (that they manage directly) is now working fine, which is enough for mail to go through even if it takes a few extra queries to get a valid response into the cache.
The clusters operated by an outside provider are still running software that has obsolete DNSSEC software. Binero and I will be reaching out to the provider to encourage them to address the issue in a timely manner. With luck, that should remediate any additional customers of that provider.
Today also saw the remediation of 26 sub-domains (which shared 3 MX hosts) of "jus.br".
So while, as a result of testing more domains, the count of problem domains had crept up to ~100 recently, it is now back down to 84. and I've reached out to the provider for 25 of those and hope to make some progress.
The issues are mostly the usual ones:
* Incorrect handling of "denial of existence" in older versions of PowerDNS.
* Blocking of queries with "unexpected" RRtypes for "security" reasons. This sadly includes "TLSA" queries in some nameservers.
[ Avoid the "security" features of InfoBlox and Arbor Networks DNS servers that do this. ]
* Similar blocking in firewalls that filter DNS queries.
* Use of secondary nameservers that only support NSEC records to slave domains that use NSEC3.
You can check for properly working DNSSEC via:
http://dnsviz.net/d/_25._tcp.<mxhostname>/dnssec/
There should be zero "bogus" replies and no "errors" or "warnings".
For comparison my list of working DANE enabled domains now has ~1800 entries. Keep adding more, but don't forget:
https://dane.sys4.de/common_mistakes
and especially:
https://dane.sys4.de/common_mistakes#3
In other news, the draft-ietf-dane-ops document is scheduled for the IESG telechat today, and should soon reach the RFC editor queue.
This will unblock the publication of the SMTP draft, which was waiting for this normative reference to get approved. Thus I expect that the SMTP, SRV and "ops" drafts will soon all be proper standards-track RFCs. Perhaps that'll help with mainstream adoption.
On Thu, Aug 06, 2015 at 06:20:01AM +0000, Viktor Dukhovni wrote:
The clusters operated by an outside provider are still running software that has obsolete DNSSEC software. Binero and I will be reaching out to the provider to encourage them to address the issue in a timely manner. With luck, that should remediate any additional customers of that provider.
The outside provider has acknowledged the software defect, and will be working on a fix. This may take a bit of time, because they have an in-house developed DNS server, so it is not just a matter of upgrading to an existing already fixed software release.
* Incorrect handling of "denial of existence" in older versions of PowerDNS.
Speaking of poor handling of denial of existence, is anyone on this list a DNS hosting customer of "isphuset.no"? I am not having much luck getting them to respond to an open ticket about 26 domains they serve that seem to have the above issue. If you are a customer, you might have better luck getting them to respond to ticket:
#WWP-ISPH-922-70734
Alternatively, if you know any of the technical staff there, please drop them a note. The problem domains are:
amihotel.no apilar.no aprilarkitekter.no bgresearch.no binzel.no cyclingnorway.no eh-bygg.no fikse-design.no flashmedia.no golfhandelen.no gustavsenas.no human-resources.no internot.no kajakkspesialisten.no klimasystem.no norskaudioteknikk.no olympic.no partnerline.no quint.no rfi.no scansat.no schou-andreassen.no shad.no spoe.no ti-industrier.no zelektro.no
and DANE SMTP servers will defer all main to these domains because TLSA record lookups SERVFAIL.
On Tue, Aug 18, 2015 at 05:02:22AM +0000, Viktor Dukhovni wrote:
* Incorrect handling of "denial of existence" in older versions of PowerDNS.Speaking of poor handling of denial of existence, is anyone on this list a DNS hosting customer of "isphuset.no"? I am not having much luck getting them to respond to an open ticket about 26 domains they serve that seem to have the above issue. If you are a customer, you might have better luck getting them to respond to ticket:
#WWP-ISPH-922-70734
It looks like this issue will be addressed in the near future.
Another DNS hosting provider (metaregistrar.nl) has upgraded PowerDNS and no longer returns incorrect "authenticated denial of existence" responses.
With a bit of luck, a few more will fix similar issues in the not too distant future.
On Tue, Aug 18, 2015 at 05:02:22AM +0000, Viktor Dukhovni wrote:
Speaking of poor handling of denial of existence, is anyone on this list a DNS hosting customer of "isphuset.no"?
#WWP-ISPH-922-70734
While the isphuset.no issue is still open, I have some good news on that front:
Though no firm date at this time, the issue has not been dropped, it seems that upgraded software is undergoing internal testing, and once some issues have been ironed out will eventually be rolled out.
The "mail.mil" DNS server folks are working on their DNS issue, and today for the first time one the name servers for "mail.mil" and similar domains has started responding to TLSA queries. With a bit luck the rest will soon follow, but already DANE-enabled servers should be able to reach the domains below (perhaps after a couple of retries if DNS queries initially fail) without explicit work-arounds:
fai.gov afnoc.af.mil afms.mil centcom.mil dau.mil dc3.mil dcaa.mil dcma.mil deca.mil defenselink.mil dfas.mil dimhrs.mil dla.mil dma.mil dmdc.mil doded.mil dodig.mil dsca.mil dss.mil dtra.mil forge.mil homes.mil jfcom.mil jsf.mil jten.mil mail.mil militaryonesource.mil navy.mil nga.mil osd.mil pacom.mil pentagon.mil pfpa.mil sapr.mil soc.mil stratcom.mil uscg.mil usmc.mil ustranscom.mil whs.mil
Really good news.
Quoting Viktor Dukhovni ietf-dane@dukhovni.org:
On Tue, Aug 18, 2015 at 05:02:22AM +0000, Viktor Dukhovni wrote:
Speaking of poor handling of denial of existence, is anyone on this list a DNS hosting customer of "isphuset.no"?
#WWP-ISPH-922-70734While the isphuset.no issue is still open, I have some good news on that front:
Though no firm date at this time, the issue has not been dropped, it seems that upgraded software is undergoing internal testing, and once some issues have been ironed out will eventually be rolled out.The "mail.mil" DNS server folks are working on their DNS issue, and today for the first time one the name servers for "mail.mil" and similar domains has started responding to TLSA queries. With a bit luck the rest will soon follow, but already DANE-enabled servers should be able to reach the domains below (perhaps after a couple of retries if DNS queries initially fail) without explicit work-arounds:
fai.gov afnoc.af.mil afms.mil centcom.mil dau.mil dc3.mil dcaa.mil dcma.mil deca.mil defenselink.mil dfas.mil dimhrs.mil dla.mil dma.mil dmdc.mil doded.mil dodig.mil dsca.mil dss.mil dtra.mil forge.mil homes.mil jfcom.mil jsf.mil jten.mil mail.mil militaryonesource.mil navy.mil nga.mil osd.mil pacom.mil pentagon.mil pfpa.mil sapr.mil soc.mil stratcom.mil uscg.mil usmc.mil ustranscom.mil whs.mil-- Viktor.
participants (8)
-
Felix Eckhofer -
James Cloos -
Jeremy Harris -
lst_hoe02＠kwsoft.de -
Patrick Domack -
Raoul Bhatia -
Viktor Dukhovni -
Wolfgang Breyha