- dane-users - list.sys4.de

Recording of DANE talk at ICANN61
by Viktor Dukhovni 17 Mar '18

17 Mar '18

I gave a talk about DANE for SMTP at the ICANN61 conference last week. Audio and slides are available, but not a synchronized recording so if you want to follow along you'll need to figure out the slide transitions from the context of the audio. I was promised 45 minutes, had too much material even for that, but only got 35 minutes, and yet managed to get to most of the key points. I hope and think that the pace was not too fast to get the points across. My segment starts at 16 minutes into the recording and ends 51 minutes into the recording: http://audio.icann.org/meetings/sju61/sju61-OPEN-2018-03-14-T1732-208bc-zYh… The slides are at: https://static.ptbl.co/static/attachments/169319/1520904692.pdf The slides have additional material in the Appendix section. Please take the key rotation advice in the slides seriously and apply it to improve your own practices. May your TLSA records never fail to validate, even briefly... -- Viktor.

1 0

DNSSEC with OpenDNS
by Michael Schwartzkopff 01 Mar '18

01 Mar '18

Hi, yesterday I heard a talk form OpenDNS (Cisco: umbrella). They told me that they will implement DNSSEC this year. Mit freundlichen Grüßen, -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein

3 2

Update on stats 2018-02
by Viktor Dukhovni 01 Mar '18

01 Mar '18

Summary: The total domain count is largely unchanged at 176970 The number DNSSEC domains in the survey stands at 5188779, thus DANE TLSA is deployed on 3.41% of domains with DNSSEC. Many DNSSEC domains use third-party MX hosts, that don't have DNSSEC, so they can't benefit from DANE until their providers secure the MX hosts. Please ask your provider to enable DNSSEC and DANE on their MX hosts. [ It would be especially significant if "redirect.ovh.net" were to implement DNSSEC+DANE. If someone personally knows the right people to gently nudge at ovh.net, please do. ] As of today I count 176970 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 handful of DNS/hosting providers who've enabled DANE support in bulk for the domains they host. The top 10 MX host providers by domain count are: 68354 domeneshop.no 63810 transip.nl 18587 udmedia.de 6202 bhosted.nl 1749 nederhost.nl 1231 yourdomainprovider.net 742 ec-elements.com 543 surfmailfilter.nl 517 core-networks.de 411 omc-mail.com The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.nl/.de. 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): 1286 DE, Germany 843 US, United States 464 NL, Netherlands 337 FR, France 190 GB, United Kingdom 112 CZ, Czech Republic 85 CA, Canada 60 CH, Switzerland 59 SE, Sweden 56 BR, Brazil IPv6 is still comparatively rare for MX hosts, and the top 10 countries by DANE MX host IPv6 GeoIP are (same top 6). 698 DE, Germany 382 US, United States 249 NL, Netherlands 190 FR, France 99 GB, United Kingdom 61 CZ, Czech Republic 35 SE, Sweden 27 SG, Singapore 25 CH, Switzerland 13 SI, Slovenia There are 3220 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 5219. These cover 5127 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 126 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 72 are in recent reports: gmx.at posteo.de overheid.nl travelbirdbelgique.be ruhr-uni-bochum.de pathe.nl nic.br tum.de uvt.nl registro.br uni-erlangen.de xs4all.nl gmx.ch unitybox.de domeneshop.no open.ch unitymedia.de handelsbanken.no anubisnetworks.com web.de webcruitermail.no gmx.com dk-hostmaster.dk aegee.org isavedialogue.com egmontpublishing.dk debian.org mail.com netic.dk freebsd.org solvinity.com tilburguniversity.edu gentoo.org trashmail.com insee.fr ietf.org xfinity.com octopuce.fr isc.org xfinityhomesecurity.com comcast.net netbsd.org xfinitymobile.com dd24.net openssl.org bayern.de dns-oarc.net samba.org bund.de gmx.net torproject.org elster.de hr-manager.net asf.com.pt fau.de mpssec.net handelsbanken.se freenet.de t-2.net minmyndighetspost.se gmx.de xs4all.net skatteverket.se jpberlin.de bhosted.nl t-2.si lrz.de boozyshop.nl mail.co.uk mail.de ouderportaal.nl govtrack.us Of the ~177000 domains, 1000 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 144. Below is the list of underlying MX hosts that serve these domains and whose TLSA records don't match reality: Hall of Shame: white.agoracon.at mail.seslost.cz mx.datenknoten.me mail.dipietro.id.au mail.zionbit.cz rootbox.me eclipse.id.au mail.3c7.de mail.castleturing.net mx.krb.srv.pique.net.au mail.absynth.de mail.culm.net zebulon.pique.net.au mail.all4.de anubis.delphij.net eufront.stansoft.bg mail.awesome-it.de mail.diejanssens.net eumembers.stansoft.bg vm-1.eveng.de mail.efflam.net andbraiz.com mail.jo8.de smtp.bl.lybre.net mail.digitalwebpros.com mx2.mindrun.de mail.fscker.nl smtp-1.httrack.com www.mtg.de smtp1.lococensus.nl mail.i-bible.com mx2.pfp.de smtp2.lococensus.nl smtp.klam.com mail.scrz44.de mail.myzt.nl demo.liveconfig.com mail.secufon.de bounder.steelyard.nl intranet.nctechcenter.com mail.secure-chat.de webmail.vivisol.nl ma.qbitnet.com mx10.timotoups.de mail.abanto-zierbena.org diablo.sgt.com mail.diplomatic.email eumembers.datacentrix.org tusk.sgt.com anotherone.braceyourself.es genius.konundrum.org stmics01.smia-automotive.com mail.0pc.eu smtp-01.tabalen.org stmics02.smia-automotive.com gamepixel.eu mail.bacrau.ro romulus.wittsend.com mail2.subse.eu mail.itconnect.ro mail.zx.com servmail.fr mx.itconnect.ro mail.allq.cz mail.victorycity.com.hk mail.pasion.ro mx2.aquasoft.cz mail.demongeot.info mail.familie-sander.rocks mx.bels.cz mail.nonoserver.info mx1.shevaldin.ru mail.davidbodnar.cz mx1.email.youwerehere.info mail.labbrack.se owl.net-art.cz mx2.email.youwerehere.info mail1.puggan.se gaia.nfx.cz masrv.dedyn.io mail.rostit.se petg.cz mail.rapidfuse.io mail.amail.si Please make sure to monitor the validity of your TLSA records, and implement a reliable key rotation procedure. Let's Encrypt users in particular tend to forget that by default Let's Encrypt certificate renewal replaces both the key and certificate, please read: https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436… https://www.ietf.org/mail-archive/web/uta/current/msg01498.html https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766 https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certifi… https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-… http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 After eliminating parked domains that do not accept email of any kind, the number of "real" email domains with bad DNSSEC support stands at 112. The top 8 (the rest have too few domains to include in a top 10) name server operators with problem domains are: 21 firstfind.nl 7 active24.cz 6 tse.jus.br 5 metaregistrar.nl 4 ignum.com 4 glbns.com 4 army.mil 4 1cocomo.com All DNS-broken domains that appear in historical Google Email transparency reports have at least one working nameserver. -- 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

A sensible "3 1 1" + "3 1 1" key rotation approach
by Viktor Dukhovni 16 Feb '18

16 Feb '18

To avoid (even temporary) mismatches always publish multiple (two are enough) TLSA records. One for matching the current certificate chain, and another matching the *future* certificate chain. You might ask how the *future* certificate chain can be predicted, but the answer is simple enough. While you may not know all the certificate details, you can control the public key that goes into the future certificate. This can be matched with a "3 1 1" record. Therefore, the recommended key rotation approach is: 1. Whenever you *deploy* a certificate chain with a new key, at the same time (that way you won't forget later) generate the next key! And that time update your TLSA records to match both keys. You only need the next public key for this, the next private key could be password protected if you like, but for most sites just rotating the keys often and letting the OS protect the keys from all but the authorized account is enough. _25._tcp.smtp.example.com. IN TLSA 3 1 1 <sha256(curr key)> _25._tcp.smtp.example.com. IN TLSA 3 1 1 <sha256(next key)> 2. When it is time to obtain a new certificate, generate the CSR from the previously generated *next* key (this may require decryption of the private if stored encrypted initially) and request the certificate, *but* do that only if the corresponding TLSA record is already published! Do the DNS lookup to verify. 3. To deploy the newly obtained certificate go back to step 1. -- Viktor.

1 0

Testing for DANE: MECSA by European Commission, Internet.nl and more
by Bart Knubben 15 Feb '18

15 Feb '18

Hi, The European Commission lately launched a tool called "My Email Communications Security Assessment (MECSA)". It also checks for DANE records. See: https://mecsa.jrc.ec.europa.eu/ There are others tools as well which are testing for DANE records on receiving mailservers (inbound) like https://internet.nl (an initiative of the Dutch Internet community and government). See for example the following test report: https://en.internet.nl/mail/internet.nl/69612/#control-panel-20 And of course there is https://dane.sys4.de that checks DANE records. For testing DANE validation when sending mail (outbound) you could use https://havedane.net/ -- Best regards, Bart Knubben

1 0

Upgrade unbound resolver to 1.6.8 if used for DANE
by Viktor Dukhovni 05 Feb '18

05 Feb '18

If you're using unbound as your local DNSSEC-validating resolver and have enabled DANE, an issue is resolved in unbound 1.6.8 where NSEC records for wildcards could be misused for invalid denial-of-existence proofs. See: https://medium.com/nlnetlabs/the-peculiar-case-of-nsec-processing-using-exp… https://unbound.net/downloads/CVE-2017-15105.txt The first article mentions that the same issue affected PowerDNS and Dnsmasq. So if you're using one of those, you might also need to update. While Google's public DNS was also affected, this is out of scope for DANE, as you get little security from relying on the AD bit from remote resolvers. -- Viktor.

1 0

Update on stats 2018-01
by Viktor Dukhovni 01 Feb '18

01 Feb '18

Summary: The total domain count has increased from 176079 to 176941 The number DNSSEC domains in the survey stands at 5188318, thus DANE TLSA is deployed on 3.41% of domains with DNSSEC. Many DNSSEC domains use third-party MX hosts, that don't have DNSSEC, so they can't benefit from DANE until their providers secure the MX hosts. Please ask your provider to enable DNSSEC and DANE on their MX hosts. [ It would be especially significant if "redirect.ovh.net" were to implement DNSSEC+DANE. If someone personally knows the right people to gently nudge at ovh.net, please do. ] As of today I count 176941 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 handful of DNS/hosting providers who've enabled DANE support in bulk for the domains they host. The top 10 MX host providers by domain count are: 68675 domeneshop.no 63512 transip.nl 18579 udmedia.de 6268 bhosted.nl 1752 nederhost.nl 1248 yourdomainprovider.net 880 ec-elements.com 517 core-networks.de 398 omc-mail.com 392 mailbox.org The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.nl/.de. Speaking of countries, the IPv4 GeoIP distribution of DANE-enabled MX hosts shows the below top 11 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented): 1282 DE, Germany 802 US, United States 453 NL, Netherlands 326 FR, France 175 GB, United Kingdom 111 CZ, Czech Republic 84 CA, Canada 62 SE, Sweden 60 CH, Switzerland 53 SG, Singapore 53 BR, Brazil IPv6 is still comparatively rare for MX hosts, and the top 10 countries by DANE MX host IPv6 GeoIP are (same top 6): 279 DE, Germany 144 US, United States 119 NL, Netherlands 74 FR, France 35 GB, United Kingdom 27 CZ, Czech Republic 15 SE, Sweden 9 SG, Singapore 9 CH, Switzerland 8 SI, Slovenia There are 3125 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 4856. These cover 4948 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 127 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 76 are in recent reports: gmx.at mail.de overheid.nl travelbirdbelgie.be posteo.de pathe.nl travelbirdbelgique.be ruhr-uni-bochum.de uvt.nl nic.br tum.de xs4all.nl registro.br uni-erlangen.de domeneshop.no gmx.ch unitybox.de handelsbanken.no open.ch unitymedia.de webcruitermail.no switch.ch web.de aegee.org anubisnetworks.com dk-hostmaster.dk debian.org gmx.com egmontpublishing.dk freebsd.org isavedialogue.com netic.dk gentoo.org mail.com tilburguniversity.edu ietf.org solvinity.com insee.fr isc.org trashmail.com octopuce.fr netbsd.org xfinity.com comcast.net openssl.org xfinityhomesecurity.com dd24.net samba.org xfinitymobile.com dns-oarc.net torproject.org nic.cz gmx.net asf.com.pt bayern.de hr-manager.net handelsbanken.se bund.de mpssec.net minmyndighetspost.se elster.de t-2.net skatteverket.se fau.de xs4all.net t-2.si freenet.de bhosted.nl mail.co.uk gmx.de boozyshop.nl govtrack.us jpberlin.de hierinloggen.nl lrz.de ouderportaal.nl Of the ~177000 domains, 786 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 232. This, despite all appearances to the contrary, is an improvement on last month, since other than a recent new batch of 72 little-known domains served by "mail.apteo.com", the overall number of problem MX hosts has declined from 102 to 86. Below is the list of underlying MX hosts that serve these domains and whose TLSA records don't match reality: Hall of Shame: white.agoracon.at mail.absynth.de anubis.delphij.net mail.dipietro.id.au mail.all4.de mail.diejanssens.net eclipse.id.au mx2.mindrun.de mail.efflam.net mx.krb.srv.pique.net.au www.mtg.de smtp.bl.lybre.net zebulon.pique.net.au mx2.pfp.de mail.fscker.nl eufront.stansoft.bg relay.rsxc.de smtp1.lococensus.nl eumembers.stansoft.bg thores-zimmer.de smtp2.lococensus.nl mx0.reich-trade.ch mx10.timotoups.de mail.myzt.nl andbraiz.com mx20.timotoups.de bounder.steelyard.nl mail.apteo.com anotherone.braceyourself.es webmail.vivisol.nl mail.digitalwebpros.com mail.0pc.eu mail.abanto-zierbena.org mail.dnsmadefree.com gamepixel.eu hydra.aufbix.org smtp-1.httrack.com smtp.skolovi.eu hydra-ipv4.aufbix.org mail.i-bible.com mail2.subse.eu eumembers.datacentrix.org demo.liveconfig.com mx.quentindavid.fr genius.konundrum.org miqote.com servmail.fr mx2.maicolepape.org srv2.noneuclideanconcepts.com mx.pushidrosal.id itaskmanager.ovh diablo.sgt.com mail.demongeot.info mail.bacrau.ro tusk.sgt.com mail.nonoserver.info mail.itconnect.ro stmics01.smia-automotive.com mx1.email.youwerehere.info mx.itconnect.ro stmics02.smia-automotive.com mx2.email.youwerehere.info mail.pasion.ro romulus.wittsend.com kd2.io mail.familie-sander.rocks mail.zx.com mail.rapidfuse.io mx1.shevaldin.ru mx2.aquasoft.cz mx.datenknoten.me mail.labbrack.se mx.bels.cz rootbox.me mail.rostit.se mail.davidbodnar.cz backup.heikorichter.name mail.amail.si gaia.nfx.cz www.heikorichter.name mail.xn----ymcadjpj1at5o.xn--wg mail.seslost.cz mail.castleturing.net secdns1.posix.co.za mail.zionbit.cz mail.culm.net Please make sure to monitor the validity of your TLSA records, and implement a reliable key rotation procedure. Let's Encrypt users in particular tend to forget that by default Let's Encrypt certificate renewal replaces both the key and certificate, please read: http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436… https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766 https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certifi… https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-… http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 When updating the certificate chain you need to temporarily pre-publish multiple TLSA records matching the current and future certificate: https://dane.sys4.de/common_mistakes#3 However, with "3 1 1" + "2 1 1", the rollover process can be substantially simplified: http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436… https://www.ietf.org/mail-archive/web/uta/current/msg01498.html After eliminating parked domains that do not accept email of any kind, the number of "real" email domains with bad DNSSEC support stands at 118. The top 7 (the rest have too few domains to include in a top 10) name server operators with problem domains are: 23 firstfind.nl 7 active24.cz 6 tse.jus.br 4 ignum.com 4 glbns.com 4 army.mil 4 1cocomo.com Only 1 DNS-broken domain has no working nameservers and also appears in historical Google Email transparency reports: tiviths.com.br The problem DNS query is: _25._tcp.mx.tiviths.com.br [ See <https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08>, Much of the TLSA non-response issue seems to be related to a "feature" of some firewalls, that enables droping of DNS requests for all but the most common RRtypes. Do not make the mistake of enabling this firewall "feature". ] The oldest outstanding DNS issue is an SOA signature issue at truman.edu dating back to Nov/2014: http://dnsviz.net/d/_25._tcp.barracuda.truman.edu/VGzORw/dnssec/ I hope some day soon they'll start missing email they care about and take the time to resolve the problem. -- 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.sys4.net IPv6 problem
by Karol Augustin 22 Jan '18

22 Jan '18

Hi, Until recently I was using HE tunnel as IPv6 provider until AWS enabled native IPv6 support in my region and everything was working without problems. Since I have enabled native IPv6 on my mail server and have problem with DANE tester site https://dane.sys4.de/smtp/augustin.pl It always times out on IPv6 address and I am confident that everything is configured properly as I receive lots of connections by IPv6 including gmail, Debian and Postfix mailing lists etc. Jan 20 06:32:38 mail postfix/postscreen[17537]: CONNECT from [2604:8d00:0:1::4]:54406 to [2a05:d018:76d:5af6:d050:9b30:6bf7:df98]:25 Jan 20 06:32:38 mail postfix/postscreen[17537]: WHITELISTED [2604:8d00:0:1::4]:54406 Jan 20 06:32:38 mail postfix/smtpd[17538]: connect from russian-caravan.cloud9.net[2604:8d00:0:1::4] Jan 20 06:32:39 mail postfix/smtpd[17538]: Trusted TLS connection established from russian-caravan.cloud9.net[2604:8d00:0:1::4]: TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits) You can see test results here: https://network-tools.webwiz.net/email-test.htm?email=augustin%2Epl&connect… Is there any known problem with DANE tester IPv6 configuration? I appreciate your help. Karol -- Karol Augustin karol(a)augustin.pl http://karolaugustin.pl/

3 7

http://dnsviz.net/d/_25._tcp.sisim1.systemec.nl/dnssec/
by Andreas Schulze 17 Jan '18

17 Jan '18

Hello, we found messages to MONTAGEBEDRIJFVANDERPLUIJM.NL undeliverable because postfix/unbound could not fetch _25._tcp.sisim1.systemec.nl The nameservers deny the existence of _tcp.$MXhost.systemec.nl. As our unbound uses QNAME minimization that result in _25._tcp.$MXhost.systemec.nl. also fail. dig @ns.systemec.NL. _tcp.sisim2.systemec.NL any +dnssec ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.9.6-P1 <<>> @ns.systemec.NL. _tcp.sisim2.systemec.NL any +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 769 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1680 ;; QUESTION SECTION: ;_tcp.sisim2.systemec.NL. IN ANY ;; AUTHORITY SECTION: systemec.NL. 3600 IN SOA ns.systemec.NL. postmaster.systemec.NL. 2017113006 28800 7200 604800 3600 systemec.NL. 3600 IN RRSIG SOA 14 2 3600 20180125000000 20180104000000 39248 systemec.nl. mtn3UO0IJXb1WA+2qEp7kYTlqaOAU7qrUcizVJCLQ6Tuda4qgd7fPAO5 qZY9FBQdiP/l4YEEeooZJyMtQilHlLiDK7MBIarIjdNSF2qQrk5hfo1a LJzs5pNW1upEdR51 sisim2.systemec.NL. 3600 IN NSEC _25._tcp.sisim2.systemec.nl. A RRSIG NSEC sisim2.systemec.NL. 3600 IN RRSIG NSEC 14 3 3600 20180125000000 20180104000000 39248 systemec.nl. UUcvXFNUVhyOUHka2Md64YKUNVownhfBsly32lqxHYKJ62JV4/x1XXV/ ckROX7CmON8MvNyVAB8FC1p1qGdjOo+Df1jpJ7oduukbEOqCeOVWdQbO 29CrRHe+84Wl/6iz ;; Query time: 18 msec ;; SERVER: 89.20.90.102#53(89.20.90.102) ;; WHEN: Wed Jan 17 11:03:38 CET 2018 ;; MSG SIZE rcvd: 429 The expected answer is "NOERROR" because the are no valid RRs for that label bit there exist childs ( _25. ) Is the correct term for that "ENT" "Empty non terminal" ??? Maybe someone can relay that information to systemec.nl DNS admins. We implemented a workaround via smtp_tls_policy_maps: "$DOMAIN -> may" until that is fixed. -- A. Schulze DATEV eG

1 1

EU Commission formally recognizes DANE
by Bart Knubben 12 Jan '18

12 Jan '18

Hi, "The European multi-stakeholder platform on ICT standardisation evaluated and gave a positive advice to the identification of the following technical specifications for referencing in public procurement: 'SPF-Sender Policy Framework for Authorizing Use of Domains in Email' ('SPF'), 'STARTTLS-SMTP Service Extension for Secure SMTP over Transport Layer Security' ('STARTTLS-SMTP') and 'DANE-SMTP Security via Opportunistic DNS-Based Authentication of Named Entities Transport Layer Security' ('DANE-SMTP') developed by Internet Engineering Task Force (IETF); [...] The evaluation and advice of the platform was subsequently submitted to consultation of sectoral experts who confirmed the positive advice to its identification." "THE EUROPEAN COMMISSION, [...] HAS ADOPTED THIS DECISION: Article 1, The technical specifications listed in the Annex are eligible for referencing in public procurement." For more details please see: http://eur-lex.europa.eu/ legal-content/EN/TXT/?qid=1515759784644&uri=CELEX:32017D2288 -- Best regards, Bart Knubben

1 0