September 2018 - dane-users

Overview of outbound DANE for SMTP support
by Knubben, B.S.J. (Bart) - Forum Standaardisatie 26 May '21

26 May '21

Hi, We made the following overview of products/services with outbound DANE support (i.e. DANE verification). Any remarks/additions are welcome. I. Supported: - Postfix (since version 2.11.0, January 2014): http://www.postfix.org/TLS_README.html#client_tls_dane - Halon (since version 3.4-r2, November 2015): https://halon.io/dane and https://wiki.halon.io/DANE - OpenSSL (since version 1.1.0, August 2016): https://www.openssl.org/docs/manmaster/man3/SSL_CTX_dane_enable.html and https://www.openssl.org/docs/manmaster/man1/openssl-s_client.html - Cloudmark (since version 5.2, March 2017): https://blog.cloudmark.com/2017/03/27/dane-and-email-security/ - Exim (since version 4.91, April 2018): https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp… - Mail-in-a-Box (uses Postfix): https://github.com/mail-in-a-box/mailinabox/blob/master/security.md - ldns (uses OpenSSL): https://www.nlnetlabs.nl/documentation/ldns/dane_8h.html II. Requested: - Cisco: Bug ID: CSCuo87918 - [ Feature Request] TLS DANE Support for Email Security Appliance, https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuo87918/ - MS O365: https://office365.uservoice.com/forums/273493-office-365-admin/suggestions/… and https://office365.uservoice.com/forums/289138-office-365-security-complianc… - Fortinet: https://fortinet.uservoice.com/forums/23797-fortipartner-feature-requests/s… - Protonmail: https://protonmail.uservoice.com/forums/284483-feedback/suggestions/3433882… and https://protonmail.uservoice.com/forums/284483-feedback/suggestions/1659360… BTW a simple outbound DANE test can be found on https://havedane.net. -- Best regards, Bart Knubben Dutch Standardisation Forum https://www.forumstandaardisatie.nl/content/english Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

5 6

Update on stats 2018-09
by Viktor Dukhovni 30 Sep '18

30 Sep '18

Credits: The coverage of DNSSEC domains continues to improve with ongoing data support from Paul Vixie of Farsight Security. Credits also due to ICANN for gTLD data via CZDS, and to the TLD registries for .CH, .COM, .DK, .FR, .INFO, .LI, .NAME, .NL, .NU, .ORG and .SE. More data sources of ccTLD signed delegations welcome. Summary: The DANE domain count is now 316,920 The number DNSSEC domains in the survey stands at 8,986,410. Thus DANE TLSA is deployed on 3.52% of domains with DNSSEC. This month DNSSEC denial of existence issues were resolved at KPN Internedservices (internedservices.nl or is.nl) and dotroll.com (also known as webspacecontrol.com). My thanks to both for taking action to significantly reduce the residual barriers to DANE adoption. As of today I count 316,920 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 DNS/email hosting providers who've enabled DANE support for the customer domains they host. The top 15 MX host providers by domain count are: 114384 transip.nl 96340 domeneshop.no 34676 active24.com 23670 udmedia.de 10761 bhosted.nl 3721 interconnect.nl 2533 provalue.nl 2451 nederhost.nl 1521 yourdomainprovider.net 1299 xcellerate.nl 1189 hi7.de 1062 surfmailfilter.nl 753 omc-mail.com 622 core-networks.de 591 mailbox.org The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.cz/.de/.eu/.be. 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): 4251 TOTAL 1449 DE, Germany 910 US, United States 549 NL, Netherlands 330 FR, France 158 GB, United Kingdom 128 CZ, Czech Republic 110 CA, Canada 57 SE, Sweden 56 SG, Singapore 55 CH, Switzerland IPv6 is still comparatively rare for MX hosts, and the top 10 countries by DANE MX host IPv6 GeoIP are (same top 6). 2126 TOTAL 816 DE, Germany 426 US, United States 317 NL, Netherlands 191 FR, France 70 GB, United Kingdom 70 CZ, Czech Republic 37 SE, Sweden 27 SG, Singapore 19 CH, Switzerland 17 AT, Austria There are 3571 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 5087. These cover 5449 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 168 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 86 are in recent (last 90 days of) reports: gmx.at lrz.de ouderportaal.nl transip.be mail.de overheid.nl nic.br posteo.de pathe.nl registro.br ruhr-uni-bochum.de politie.nl gmx.ch tum.de transip.nl open.ch uni-erlangen.de truetickets.nl anubisnetworks.com unitybox.de uvt.nl gmx.com unitymedia.de xs4all.nl mail.com web.de domeneshop.no societe.com dk-hostmaster.dk handelsbanken.no solvinity.com egmontpublishing.dk rushtrondheim.no t-2.com netic.dk webcruitermail.no trashmail.com tilburguniversity.edu aegee.org xfinity.com insee.fr debian.org xfinityhomesecurity.com octopuce.fr freebsd.org xfinitymobile.com comcast.net gentoo.org active24.cz gmx.net ietf.org cuni.cz hr-manager.net isc.org destroystores.cz inexio.net netbsd.org klubpevnehozdravi.cz mpssec.net openssl.org optimail.cz t-2.net samba.org smtp.cz transip.net torproject.org bayern.de xs4all.net asf.com.pt bund.de bhosted.nl handelsbanken.se elster.de boozyshop.nl minmyndighetspost.se fau.de deltion.nl skatteverket.se freenet.de hierinloggen.nl t-2.si gmx.de interconnect.nl govtrack.us jpberlin.de intermax.nl Of the ~317000 domains, 1390 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 258. Some of these have additional MX hosts that don't have broken TLSA records, so mail can still arrive via the remaining MX hosts. A partial list is available at: https://github.com/danefail/list To avoid getting listed, please make sure to monitor the validity of your own TLSA records, and implement a reliable key rotation procedure. See: https://dane.sys4.de/common_mistakes http://imrryr.org/~viktor/ICANN61-viktor.pdf http://imrryr.org/~viktor/icann61-viktor.mp3 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 The DNSSEC denial of existence breakage is lower this month, as a result of a complete resolution of all issues at is.nl and dotroll.com. After eliminating parked domains that do not accept email, the number of "real" email domains with bad DNSSEC support stands at 531. The top 20 name server operators with problem domains are: 51 dotserv.com 39 tiscomhosting.nl 35 metaregistrar.nl 33 sylconia.net 31 nrdns.nl 25 active24.cz (some broken wildcard cnames) 20 host-redirect.com 19 nazwa.pl (some broken wildcard NS RRs) 12 psb1.org 11 blauwblaatje.nl 10 eth-services.de 10 army.mil 9 vultr.com 9 dnscluster.nl 8 pcextreme.nl 8 forpsi.net 7 ovh.net 6 loopia.se 6 domdom.hu 5 1cocomo.com If anyone has good contacts at some of these providers, please encourage them to remediate not only the broken domains (I can send them a list), but also the root cause that makes the breakage possible. None of the domains all whose nameservers have broken denial of existence appear in historical Google reports. So it is likely that the DNSSEC denial of existence problems are not felt by most email senders. -- 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

Don't set the NSEC3 opt-out bit in your own zones
by Viktor Dukhovni 08 Sep '18

08 Sep '18

The NSEC3 opt-out bit allows DNS registry operators of public suffix domains (TLDs like .com, 2LDs like .co.uk, ...) where most delegations are unsigned to save CPU time and space by including only the signed delegations in their NSEC3 chain. While this is handy for such domains with lots of insecure delegations, it is otherwise a bad idea. Unless you're a TLD/2LD operator of that sort, DO NOT set the opt-bit in your NSEC3PARAM record. Here's one example of what can go wrong: http://dnsviz.net/d/_25._tcp.mail.ormanns.net/dnssec/ Until today, the ormanns.net domain used to have working secure TLSA records for its MX host: ormanns.net. IN MX 0 mail.ormanns.net. ; NoError AD=1 mail.ormanns.net. IN A 37.120.182.194 ; NoError AD=1 mail.ormanns.net. IN AAAA 2a03:4000:15:7e:: ; NoError AD=1 but then the TLSA record: _25._tcp.mail.ormanns.net. IN TLSA 3 1 1 c95ab7f0b49c1d762408d0089133d20d78c992e6e28b28c165d18e043c574ba8 was replaced with a wildcard: *._tcp.mail.ormanns.net. IN TLSA 3 1 1 c95ab7f0b49c1d762408d0089133d20d78c992e6e28b28c165d18e043c574ba8 unfortunately, while the zone is DNSSEC-signed, and the wildcard recurd is "secure", denial of existence of the removed TLSA RR for _25._tcp.mail.ormanns.net is "insecure" because of the NSEC3 opt-out bit. And so the wild-card synthesized TLSA is also "insecure" and the domain is no longer DANE-protected. One could keep the NSEC3 opt-bit bit and carefully add desired CNAMEs to share a TLSA record across services: _dane.mail.ormanns.net. IN TLSA 3 1 1 c95ab7f0b49c1d762408d0089133d20d78c992e6e28b28c165d18e043c574ba8 _25._tcp.mail.ormanns.net. IN CNAME _dane.mail.ormanns.net. _587._tcp.mail.ormanns.net. IN CNAME _dane.mail.ormanns.net. _465._tcp.mail.ormanns.net. IN CNAME _dane.mail.ormanns.net. _443._tcp.mail.ormanns.net. IN CNAME _dane.mail.ormanns.net. But, whether that's a good idea or not, it is far better to avoid NSEC3 opt-out and have secure denial of existence for all names in the zone, and then wildcards don't bring any security surprises. -- Viktor.

1 0

validation problem
by Andreas Schulze 06 Sep '18

06 Sep '18

Hello, unsure it that topic may better discussed on postfix-users.... I'm messages for <*(a)sushi-circle.de> in my outbound deferred queue. Sep 2 11:15:38 idvmailout02 postfix/smtp[73811]: 422V1C0rjyzNkGv: to=<***(a)sushi-circle.de>, relay=none, delay=88795, delays=88794/0.24/0.61/0, dsn=4.7.5, status=deferred (TLSA lookup error for login.enterprise-email.com:25) Sep 2 11:15:38 idvmailout02 postfix/smtp[73811]: warning: TLS policy lookup for sushi-circle.de/login.enterprise-email.com: TLSA lookup error for login.enterprise-email.com:25 Sep 2 11:15:38 idvmailout02 postfix/smtp[73811]: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.login.enterprise-email.com type=TLSA: Host not found, try again Sep 2 11:15:37 idvmailout02 postfix/smtp[73811]: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.login.enterprise-email.com type=TLSA: Host not found, try again I wonder, why postfix try to lookup TLSA Records for the MX at all. The destination domain sushi-circle.de is unsigned and so any TLSA for the MX don't matter. Is there any switch to influence that behavior? mail_version = 3.2.5 -- A. Schulze DATEV eG

2 3

xs4all enabled DANE outgoing verification
by Jan-Pieter Cornet 04 Sep '18

04 Sep '18

Hi, On smtp.xs4all.nl we enabled DANE outgoing verification, but currently only with a "soft fail": if DANE fails, we fallback to non-DANE delivery... for now. Except for a few hardcoded domains (currently only our own, and havedane.net). If anyone feels confident about their own DANE setup, feel free to send me your domain (or domains), and I'll add it to the list of hardfails. ... but in a few weeks we'll disable the softfail anyway, if we don't see any problems (other than the ones in the danefail list, which I'm not yet using, but the softfail is hitting some of the domains on that list already). We don't do smtp-tlsrpt reporting (yet?), but I can make some stats on demand for your domain, if you'd like that. As a word of caution to other would-be DANE implementers: we also had problems with a domain that was not on the dane-fail list. This domain had DNSSEC and TLSA records for the MX host, but did not offer STARTTLS. That would be a huge red flag, and fortunately we had the softfail fallback so mail kept on being delivered. After investigating, it turned out that this domain had *my* IPs in an exception list of "do not offer TLS", because a few years ago we hit some sort of timeout bug that caused hanging connections. The hanging connection bug has since been solved, but the IP exception was still there... So the moral of the story is: next to the domains in the dane-fail list, there might be local exceptions that might apply, so keep an eye on your logfiles. -- Jan-Pieter Cornet <johnpc(a)xs4all.net> Systeembeheer XS4ALL Internet bv www.xs4all.nl

5 11

Update on stats 2018-08
by Viktor Dukhovni 01 Sep '18

01 Sep '18

Credits: The coverage of DNSSEC domains continues to improve with ongoing data support from Paul Vixie of Farsight Security. Credits also due to ICANN for the gTLD data via CZDS, Afilias for access to .INFO zone data, data contributions from the TLD registries for .CH, .DK, .INFO, .LI, .NL and .ORG and open access for .FR, .NU and .SE. More data sources of ccTLD signed delegations welcome. Summary: The DANE domain count is now 314,472 The number DNSSEC domains in the survey stands at 8,908,099. Thus DANE TLSA is deployed on 3.52% of domains with DNSSEC. All DNSSEC denial of existence issues are resolved at mijnhostingparner.nl and tse.jus.br. As of today I count 314,472 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 DNS/email hosting providers who've enabled DANE support for the customer domains they host. The top 15 MX host providers by domain count are: 112848 transip.nl 96132 domeneshop.no 34452 active24.com 23638 udmedia.de 10651 bhosted.nl 3720 interconnect.nl 2491 provalue.nl 2456 nederhost.nl 1666 yourdomainprovider.net 1297 xcellerate.nl 1177 hi7.de 1093 surfmailfilter.nl 724 omc-mail.com 608 core-networks.de 567 mailbox.org The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.cz/.de/.eu/.be. 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): 4263 TOTAL 1453 DE, Germany 922 US, United States 541 NL, Netherlands 346 FR, France 161 GB, United Kingdom 124 CZ, Czech Republic 100 CA, Canada 58 SE, Sweden 57 SG, Singapore 56 CH, Switzerland IPv6 is still comparatively rare for MX hosts, and the top 10 countries by DANE MX host IPv6 GeoIP are (same top 6). 2066 TOTAL 813 DE, Germany 435 US, United States 309 NL, Netherlands 194 FR, France 66 GB, United Kingdom 66 CZ, Czech Republic 37 SE, Sweden 28 SG, Singapore 21 CH, Switzerland 18 AT, Austria There are 3563 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 5015. These cover 5376 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 165 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 91 are in recent reports: gmx.at jpberlin.de ouderportaal.nl transip.be lrz.de overheid.nl nic.br mail.de pathe.nl registro.br posteo.de politie.nl gmx.ch ruhr-uni-bochum.de transip.nl open.ch tum.de truetickets.nl anubisnetworks.com uni-erlangen.de utwente.nl fmc-na.com unitybox.de uvt.nl gmx.com unitymedia.de xs4all.nl mail.com web.de domeneshop.no societe.com dk-hostmaster.dk rushtrondheim.no solvinity.com egmontpublishing.dk webcruitermail.no t-2.com netic.dk aegee.org trashmail.com tilburguniversity.edu debian.org xfinity.com insee.fr freebsd.org xfinityhomesecurity.com octopuce.fr gentoo.org xfinitymobile.com comcast.net ietf.org active24.cz dd24.net isc.org cuni.cz gmx.net netbsd.org destroystores.cz hr-manager.net openssl.org klubpevnehozdravi.cz inexio.net samba.org knizni-magazin.cz mpssec.net torproject.org nic.cz t-2.net asf.com.pt optimail.cz transip.net handelsbanken.se smtp.cz xs4all.net iis.se bayern.de bhosted.nl minmyndighetspost.se bund.de boozyshop.nl skatteverket.se elster.de deltion.nl t-2.si fau.de hierinloggen.nl govtrack.us freenet.de interconnect.nl gmx.de intermax.nl Of the ~314000 domains, 1193 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 287. Some of these have additional MX hosts that don't have broken TLSA records, so mail can still arrive via the remaining MX hosts. A partial list is available at: https://github.com/danefail/list To avoid getting listed, please make sure to monitor the validity of your own TLSA records, and implement a reliable key rotation procedure. See: https://dane.sys4.de/common_mistakes http://imrryr.org/~viktor/ICANN61-viktor.pdf http://imrryr.org/~viktor/icann61-viktor.mp3 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 The DNSSEC denial of existence breakage is lower this month, as a result of a complete resolution of all issues at mijnhostingpartner.nl and tse.jus.br. After eliminating parked domains that do not accept email of any kind, the number of "real" email domains with bad DNSSEC support stands at 708. The top 20 name server operators with problem domains are: 112 webspacecontrol.com (reportedly working on a solution) 64 is.nl 51 dotserv.com 39 tiscomhosting.nl 33 sylconia.net 33 metaregistrar.nl 29 nrdns.nl 25 active24.cz (some broken wildcard cnames) 21 host-redirect.com 15 nazwa.pl (some broken wildcard NS RRs) 13 psb1.org 12 ultratek.com 11 blauwblaatje.nl 11 army.mil 9 dnscluster.nl 8 vultr.com 8 pcextreme.nl 8 glbns.com 7 forpsi.net 6 domdom.hu If anyone has good contacts at one of these providers, please encourage them to remediate not only the broken domains (I can send them a list), but also the root cause that makes the breakage possible. None of the domains all whose nameservers have broken denial of existence appear in historical Google reports. -- 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