- dane-users - list.sys4.de

Reminder DNSSEC Root KSK roll today
by Viktor Dukhovni 11 Oct '18

11 Oct '18

In case you've not seen this many other places, just a friendly reminder that ICANN is rolling the DNSSEC root KSK today. Make sure your resolver (if it is validating) is ready. If you're forwarding queries to an upstream resolver, you might also check that the upstream is ready. -- Viktor.

1 1

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

RE: Overview of outbound DANE for SMTP support
by Knubben, B.S.J. (Bart) - Forum Standaardisatie 17 Aug '18

17 Aug '18

On Tue, Jul 17, 2018, Knubben, B.S.J. (Bart) - Forum Standaardisatie wrote: > We made the following overview of products/services with outbound > DANE support (i.e. DANE verification). Any remarks/additions are > welcome. > I. Supported: Upcoming: PowerMTA 5.0 ( announcement on https://twitter.com/Port25Solutions/status/1029770765716123648 ) -- 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.

1 0

Update on stats 2018-07
by Viktor Dukhovni 01 Aug '18

01 Aug '18

Credits: The .NL registry (SIDN) have kindly provided a snapshot of the signed .NL domains. With this month's coverage of .NL domains is 100% modulo late changes. Some additional coverage growth is due to ongoing data drops from Paul Vixie of Farsight Security. Summary: The DANE domain count is now 311,725. The number DNSSEC domains in the survey stands at 8,702,087 Thus DANE TLSA is deployed on 3.58% of domains with DNSSEC. As of today I count 311,725 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: 111683 transip.nl 95899 domeneshop.no 34296 active24.com 23508 udmedia.de 10670 bhosted.nl 3768 interconnect.nl 2517 provalue.nl 2435 nederhost.nl 1681 yourdomainprovider.net 1300 xcellerate.nl 1131 hi7.de 1028 surfmailfilter.nl 702 omc-mail.com 629 core-networks.de 573 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): 4162 TOTAL 1415 DE, Germany 904 US, United States 532 NL, Netherlands 350 FR, France 158 GB, United Kingdom 122 CZ, Czech Republic 82 CA, Canada 61 SG, Singapore 61 SE, Sweden 57 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 781 DE, Germany 421 US, United States 282 NL, Netherlands 194 FR, France 90 GB, United Kingdom 66 CZ, Czech Republic 35 SE, Sweden 27 SG, Singapore 21 CH, Switzerland 15 FI, Finland There are 3474 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 4866. These cover 5216 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 159 (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 interconnect.nl travelbirdbelgique.be lrz.de intermax.nl nic.br mail.de ouderportaal.nl registro.br posteo.de overheid.nl gmx.ch ruhr-uni-bochum.de pathe.nl open.ch tum.de politie.nl anubisnetworks.com uni-erlangen.de truetickets.nl gmx.com unitybox.de uvt.nl mail.com unitymedia.de xs4all.nl societe.com web.de domeneshop.no solvinity.com dk-hostmaster.dk rushtrondheim.no t-2.com egmontpublishing.dk webcruitermail.no trashmail.com netic.dk aegee.org xfinity.com tilburguniversity.edu debian.org xfinityhomesecurity.com insee.fr freebsd.org xfinitymobile.com octopuce.fr gentoo.org active24.cz atrivio.net ietf.org clubcard.cz comcast.net isc.org cuni.cz dd24.net netbsd.org itesco.cz dns-oarc.net openssl.org klubpevnehozdravi.cz gmx.net samba.org knizni-magazin.cz hr-manager.net torproject.org nic.cz inexio.net asf.com.pt optimail.cz mpssec.net handelsbanken.se smtp.cz t-2.net iis.se bayern.de xs4all.net minmyndighetspost.se bund.de bhosted.nl skatteverket.se elster.de bit.nl t-2.si fau.de boozyshop.nl govtrack.us freenet.de deltion.nl gmx.de hierinloggen.nl Of the ~312000 domains, 1203 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 220. 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 All the new blood in the survey has uncovered some previously unseen DNSSEC denial of existence breakage. After eliminating parked domains that do not accept email of any kind, the number of "real" email domains with bad DNSSEC support stands at 881. The top 20 name server operators with problem domains are: 129 mijnhostingpartner.nl 99 webspacecontrol.com / dotroll.com 64 metaregistrar.nl 64 is.nl 51 dotserv.com 41 tiscomhosting.nl 33 sylconia.net 29 tse.jus.br 27 active24.cz (some broken wildcard cnames) 25 nrdns.nl 21 host-redirect.com 16 nazwa.pl (some broken wildcard NS RRs) 14 zeptor.nl 13 psb1.org 11 blauwblaatje.nl 11 army.mil 9 dnscluster.nl 8 pcextreme.nl 8 glbns.com 7 forpsi.net If anyone has good contacts at one of these provides, 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. The domains all whose nameservers have broken denial of existsnce that also appear in historical Google reports are: tre-ce.jus.br tre-pe.jus.br tre-rj.jus.br tre-rs.jus.br tre-sc.jus.br tre-sp.jus.br trt1.jus.br trtrj.jus.br tse.jus.br -- 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

DANE rollover: selector type
by Dennis Baaten 13 Jul '18

13 Jul '18

Hi Viktor, In your presentation named "Real World DANE Inter-domain email transport" (https://static.ptbl.co/static/attachments/169319/1520904692.pdf) you describe two approaches to handle a certificate change from a DANE perspective: "current + next", and "current + issuer CA". In the given example you use a "1" (certificate public key) for the TLSA parameter "selector". I'm wondering whether this example is meant to imply that selector type "1" is preferred over selector type "0" (full certificate)? In my opinion the selector type should not matter, making a "311 + 211" just as good as a "301 + 211". Would you agree? Regards, Dennis

2 1

DANE-TA(2) private CAs and SHA-1
by Viktor Dukhovni 13 Jul '18

13 Jul '18

By using DANE-TA(2) TLSA records you can associate your SMTP server with a either a public or private (your own) issuer CA. This can simplify the management of TLSA records of multiple MX hosts by using a CNAME to a common location where you publish the shared CA key hash. Some care needs to be take to make sure that certificate chains issued by a private CA can be successfully validated by correctly configured DANE TLS clients. 1. Make sure the MX hostname of the end-entity server is one of the names in the subjectAltName extension of the server certificate. This is optional for DANE-EE(3), but is required for DANE-TA(2). Some MX hosts are known by different names when serving different domains. I don't recommend this, but can't stop you from doing it. In that case, all the names should appear in the certificate, or (if using server-side SNI) each name should appear in the corresponding certificate. 2. Make sure that the server certificate is replaced in a timely manner before it expires. This is also optional with DANE-EE(3), and required with DANE-TA(2). 3. [The motivation for this message]. Use broadly accepted cryptographic algorithms and parameters. For example, recent versions of GnuTLS by default no longer accept SHA-1 signatures in certificate chains. Some versions of Exim that support DANE are linked with GnuTLS, and the Exim maintainers are not presently inclined to re-enable SHA-1 support. Therefore, sites using private CAs with SHA-1 signatures may encounter problems receiving some email. (Public CA/B forum CAs no longer issue SHA-1 certificates.) For best interoperability use the SHA256 digest algorithm in certificate signatures. For best interoperability, use RSA key sizes of at least 1280 bits, and no more than 4096. The most common choice is 2048-bits. For ECDSA, stick with NIST P-256 (OpenSSL names for this ECDSA curve are prime256v1 and secp256r1). Today (after most of the small number of domains using SHA-1 with private CAs re-issued their certificates) the DANE survey finds only one MX host of one domain with SHA-1 private-CA signatures: semidefinite.de. IN MX 10 mail.semidefinite.de. so the impact of the GnuTLS policy is low. With a bit of luck, this post will help others avoid the same issue, and perhaps also the postmaster of the above domain will see it on one of the dane-users, postfix-users or exim-users lists, so the number of affected domains may soon be zero. -- Viktor.

1 0