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.
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
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.orgisavedialogue.com egmontpublishing.dk debian.orgmail.com netic.dk freebsd.orgsolvinity.comtilburguniversity.edugentoo.orgtrashmail.com insee.fr ietf.orgxfinity.com octopuce.fr isc.orgxfinityhomesecurity.comcomcast.netnetbsd.orgxfinitymobile.comdd24.netopenssl.org
bayern.de dns-oarc.netsamba.org
bund.de gmx.nettorproject.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.netandbraiz.com mail.jo8.de smtp.bl.lybre.netmail.digitalwebpros.com mx2.mindrun.de mail.fscker.nl
smtp-1.httrack.comwww.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.orgdiablo.sgt.com mail.diplomatic.email eumembers.datacentrix.orgtusk.sgt.com anotherone.braceyourself.es genius.konundrum.orgstmics01.smia-automotive.com mail.0pc.eu smtp-01.tabalen.orgstmics02.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.htmlhttp://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436…https://www.ietf.org/mail-archive/web/uta/current/msg01498.htmlhttps://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766https://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.1http://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.
