Summary: The DANE domain count is now 1,714,271.
This is a substantial increase over last month, despite the data feeds from SIDN (.NL) and Farsight Security (passive DNS across all TLDs) not being ready in time for this month-end summary. The count will likely rise again, once those data sets are processed.
The number of domains that return DNSSEC-validated replies in response to MX queries is 10,448,578. This is a large increase over last month when the total was 10,133,312. Thus DANE TLSA is deployed on ~16.41% of domains with DNSSEC.
This month the DANE domain count for one.com is larger than one million. Congratulations and thanks again to one.com!
Also adoption of ECDSA P-256 (algorithm 13) continues to grow, and the number of domains using P-256 KSKs has almost reached parity with RSA-SHA256 (algorithm 8), which is just ahead for now, but likely not for very much longer.
https://stats.dnssec-tools.org/#parameter
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, .IS, .LI, .NL, .NU, .ORG and .SE. More data sources of ccTLD signed delegations welcome.
As of today I count 1,714,271 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 20 MX host providers by domain count are:
1,013,231 one.com 130,768 transip.nl 98,944 domeneshop.no 88,010 loopia.se 37,102 active24.com 31,595 vevida.com 28,681 antagonist.nl 26,461 web4u.cz 24,373 udmedia.de 17,099 bhosted.nl 16,414 zxcs.nl 15,480 flexfilter.nl 13,341 onebit.cz 8,283 protonmail.ch 5,982 netzone.ch 5,567 previder.nl 4,658 mailplatform.eu 3,563 ips.nl 3,187 interconnect.nl 2,852 zonemx.eu
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 20 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented).
5862 TOTAL 1964 DE, Germany 1166 US, United States 852 NL, Netherlands 461 FR, France 229 GB, United Kingdom 189 CZ, Czechia 118 CA, Canada 96 SG, Singapore 81 CH, Switzerland 77 SE, Sweden 64 DK, Denmark 58 FI, Finland 46 IE, Ireland 41 AT, Austria 40 AU, Australia 39 JP, Japan 38 PL, Poland 28 RU, Russia 28 BR, Brazil 24 IT, Italy
IPv6 is less common than IPv4 for MX hosts, and the top 20 countries by DANE MX host IPv6 GeoIP are:
3009 TOTAL 1248 DE, Germany 503 US, United States 434 NL, Netherlands 247 FR, France 112 CZ, Czechia 89 GB, United Kingdom 39 SE, Sweden 36 SG, Singapore 31 CH, Switzerland 30 RU, Russia 29 JP, Japan 26 CA, Canada 21 AT, Austria 19 IE, Ireland 14 SI, Slovenia 14 DK, Denmark 13 NO, Norway 12 ID, Indonesia 12 BR, Brazil 11 FI, Finland
There are 4918 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 7570. These cover 8456 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 293 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 148 are in recent (last 90 days of) reports:
univie.ac.at lrz.de minbzk.nl gmx.at mail.de mm1.nl nic.br posteo.de ouderportaal.nl registro.br ruhr-uni-bochum.de overheid.nl buymyweedonline.ca tum.de parlement.nl gmx.ch uni-erlangen.de pathe.nl open.ch uni-muenchen.de photofacts.nl protonmail.ch unitybox.de photofactsacademy.nl altospam.com unitymedia.de politie.nl anubisnetworks.com web.de previder.nl clubedominante.com egmontpublishing.dk rijksoverheid.nl fmc-na.com netic.dk ru.nl gmx.com star.dk schoudercom.nl habr.com tilburguniversity.edu schuurman-schoenen.nl hotelsinduitsland.com web200.eu ssonet.nl ingthink.com zone.eu truetickets.nl kpn.com ac-strasbourg.fr tweedekamer.nl mail.com kangouroukids.fr uitgeverijpica.nl mammoetmail.com octopuce.fr utwente.nl one.com web200.hu uvt.nl primexbt.com 247superhost.net xs4all.nl protonmail.com comcast.net domeneshop.no societe.com dns-oarc.net handelsbanken.no solvinity.com gmx.net uib.no t-2.com habramail.net webcruitermail.no telfort.com hr-manager.net atelkamera.nu trashmail.com inexio.net debian.org xfinity.com mpssec.net freebsd.org xfinityhomesecurity.com procurios.net gentoo.org xfinitymobile.com riseup.net ietf.org active24.cz t-2.net isc.org atlas.cz transip.net mailbox.org centrum.cz vevida.net netbsd.org cuni.cz xs4all.net openssl.org itesco.cz 50plusbeurs.nl ozlabs.org klubpevnehozdravi.cz belastingdienst.nl samba.org onebit.cz bhosted.nl torproject.org optimail.cz billybird.nl whatpulse.org server4u.cz bluerail.nl moikrug.ru smtp.cz boozyshop.nl boplatssyd-automail.se virusfree.cz corpoflow.nl handelsbanken.se volny.cz denhaag.nl loopia.se web4u.cz digid.nl minmyndighetspost.se bayern.de digistate.nl personligalmanacka.se bund.de ezorg.nl skatteverket.se elster.de fontys.nl theletter.se fau.de hr.nl govtrack.us freenet.de hro.nl ru.ac.za gmx.de intermax.nl jpberlin.de mailplus.nl
Of the ~1.71 million domains, 3220 have "partial" TLSA records, that cover only a subset of the (secondary) 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 462. 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 email outages, 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 https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
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, the number of "real" email domains with bad DNSSEC support stands at 1435. The top 10 name server operators with problem domains are:
400 mijnhostingpartner.nl 295 domaincontrol.com (a.k.a. Godaddy, new this month) 89 egensajt.se 53 movenext.nl 43 metaregistrar.nl 33 tiscomhosting.nl 30 eurodns.com 28 nrdns.nl 26 hostnet.nl 19 sylconia.net
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.
Twelve of the domains all whose nameservers have broken denial of existence appear in the last 120 days of Google transparency reports:
coren-sp.gov.br trt01.gov.br trtrio.gov.br trt1.jus.br trtrj.jus.br groupconcorde.com kineticcu.com xoriant.com xpressbillpay.com mobily.com.sa sauditelecom.com.sa bog.gov.sa
Hi
Viktor Dukhovni ietf-dane@dukhovni.org wrote:
Also adoption of ECDSA P-256 (algorithm 13) continues to grow, and the number of domains using P-256 KSKs has almost reached parity with RSA-SHA256 (algorithm 8), which is just ahead for now, but likely not for very much longer.
My KSK and ZSK are both of algorithm 8 and 2048 bits in size.
Is it correct to assume that -due to the growing adoption of algorithm 13- that this algorithm should be preferred? If so, I would like to migrate. But, I do have some questions to the community beforehand:
#) Can one mix KSK and ZSK algorithms?
(I do have a rollover of my ZSKs due in a couple of days. Thus starting with ZSKs would be convenient.)
#) Would it be wise to increase from 2048 to 4096 bits size?
Thanks in advance and with kind regards, Michael
Hi,
never mind, but I belief that I found an answer to one of my questions in the meantime.
Michael Grimm trashcan@ellael.org wrote:
Viktor Dukhovni ietf-dane@dukhovni.org wrote:
Also adoption of ECDSA P-256 (algorithm 13) continues to grow, and the number of domains using P-256 KSKs has almost reached parity with RSA-SHA256 (algorithm 8), which is just ahead for now, but likely not for very much longer.My KSK and ZSK are both of algorithm 8 and 2048 bits in size.
Is it correct to assume that -due to the growing adoption of algorithm 13- that this algorithm should be preferred? If so, I would like to migrate. But, I do have some questions to the community beforehand:
#) Can one mix KSK and ZSK algorithms?
(I do have a rollover of my ZSKs due in a couple of days. Thus starting with ZSKs would be convenient.)
https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over https://medium.com/nlnetlabs/algorithm-rollover-in-opendnssec-1-3-bf1dfa480a...
Both articles suggest that one should change the algorithm on both keys during a simultaneously rollover operation with additional precautions.
(Because I am using OpenDNSSEC v2 I will take the second article as a guideline.)
#) Would it be wise to increase from 2048 to 4096 bits size?
With kind regards, Michael
On Mon, Dec 02, 2019 at 11:16:56AM +0100, Michael Grimm wrote:
Viktor Dukhovni ietf-dane@dukhovni.org wrote:
Also adoption of ECDSA P-256 (algorithm 13) continues to grow, and the number of domains using P-256 KSKs has almost reached parity with RSA-SHA256 (algorithm 8), which is just ahead for now, but likely not for very much longer.My KSK and ZSK are both of algorithm 8 and 2048 bits in size.
That's mostly OK, but the 2048-bit ZSK means that denial of existence responses are likely to exceed the IPv6 MTU, and may be cause some lookup issues. With RSA, the best-practice ZSK size is likely 1280 bits, rotated often enough (every 90 days or so) to not pose significant risk of cryptanalysis.
Is it correct to assume that -due to the growing adoption of algorithm 13- that this algorithm should be preferred?
Yes. ECDSA P-256 is better suited to DNSSEC.
#) Can one mix KSK and ZSK algorithms?
This is not recommended, to switch algorithms:
0. Migrate to a 1280 or 1024-bit ZSK, to keep packet sizes down, wait a few TTLs.
1. Add and activate a P-256 ZSK, wait a few TTLs after all secondaries are serving the updated zone.
2. Add an activate a P-256 KSK, wait a few TTLs after all secondaries are serving the updated zone.
3. Update the DS record in the parent zone to match the P-256 KSK (you can now drop the DS matching the RSA KSK). Wait a few parent zone TTLs after new DS is visible in all parent zone nameservers.
4. Drop the RSA KSK from your zone, wait a few TTLs.
5. Drop the RSA ZSK from your zone. You're done.
(I do have a rollover of my ZSKs due in a couple of days. Thus starting with ZSKs would be convenient.)
* The order of addition is: ZSK -> KSK -> DS * The order of removal is: DS -> KSK -> ZSK
#) Would it be wise to increase from 2048 to 4096 bits size?
Definitely not, instead 1280 bits, but then migrate to P-256.
Viktor Dukhovni ietf-dane@dukhovni.org wrote:
On Mon, Dec 02, 2019 at 11:16:56AM +0100, Michael Grimm wrote:
Thanks for all your valuable information, I will follow your advices thoroughly ;-)
One last question:
#) Would it be wise to increase from 2048 to 4096 bits size?
Definitely not, instead 1280 bits, but then migrate to P-256.
I will migrate both KSK and ZSK to P-256. I understood that a ZSK should be of size 1280 bits, but what is the optimal size of a P-256 KSK [1]?
Thanks and with kind regards, Michael
[1] current rollover period is 10 years, which might be modified as well.
On Mon, Dec 02, 2019 at 08:14:30PM +0100, Michael Grimm wrote:
Definitely not, instead 1280 bits, but then migrate to P-256.
That 1280 bit advice is RSA-only. RSA has variable-size keys.
I will migrate both KSK and ZSK to P-256. I understood that a ZSK should be of size 1280 bits, but what is the optimal size of a P-256 KSK [1]?
Best-practice for an *RSA* ZSK is ~1280 bits, but P-256 has fixed size keys, so the question does not make sense...
The key blob (in "uncompressed" point format) is 512 bits, but we simply don't talk about key bits with EC crypto, instead we talk about choices of "curve" (which imply the key and signature sizes). P-256 is the most widely used EC curve. It is gradually being superseded by Ed25519, but too few DNS resolvers support Ed25519 to make it a practical choice for DNSSEC just yet.
Viktor Dukhovni ietf-dane@dukhovni.org wrote:
[…] P-256 has fixed size keys, so the question does not make sense…
Ah, now! Understood, and again thanks for your information.
Kind regards, Michael
On 2019/12/02 12:16, Michael Grimm wrote:
Hi
Viktor Dukhovni ietf-dane@dukhovni.org wrote:
Also adoption of ECDSA P-256 (algorithm 13) continues to grow, and the number of domains using P-256 KSKs has almost reached parity with RSA-SHA256 (algorithm 8), which is just ahead for now, but likely not for very much longer.
I run a small ISP in South Africa - with about 2000 domains. About 200 of these are DNSSEC signed. I'm in the process of migrating them from algo 8 to algo 13. Its all scripted and the conversions are all happening automatically. *The KSK-ZSK chain has to be complete**through with at least one common Algorithm.* I also don't want to re-sign everything at the same time - so everything is spread out over a year. I keep KSK's for a year and ZSK's for a month. ZSK's are dealt with totally internally where as a KSK rollover means talking to the Parent zone and changing DS records - so I'm timing everything with my KSK's.
When a KSK is due to roll, create both a Algo-13 KSK and ZSK. iUpload the appropriate DS. Once the new DS record is "seen" (and give it another day) - then delete the old DS, KSK and ZSK.
The KSK and ZSK signatures are much shorter - so you are less lightly to be used as a DDOS source for a DNS Denial of service attack (the amplification is way lower).
*You don't need to increase the Key Size. *
My KSK and ZSK are both of algorithm 8 and 2048 bits in size.
Is it correct to assume that -due to the growing adoption of algorithm 13- that this algorithm should be preferred? If so, I would like to migrate. But, I do have some questions to the community beforehand:
#) Can one mix KSK and ZSK algorithms?
(I do have a rollover of my ZSKs due in a couple of days. Thus starting with ZSKs would be convenient.)#) Would it be wise to increase from 2048 to 4096 bits size?
Thanks in advance and with kind regards, Michael
On Mon, Dec 02, 2019 at 08:01:27PM +0200, Mark Elkins wrote:
I run a small ISP in South Africa - with about 2000 domains. About 200 of these are DNSSEC signed.
Hello Mark, good to see you're on the dane-users list.
For 49 of the 200 domains, my DANE survey is chronically unable to validate the TLSA RR of the secondary MX (secdns1.posix.co.za):
_25._tcp.secdns1.posix.co.za. IN TLSA 3 1 1 a82d33d63d9c4acea043007041c0c99839f1805e5755e54c9d32ced02cc790ea secdns1.posix.co.za[192.96.24.81]: STARTTLS 454 TLS currently unavailable secdns1.posix.co.za[2001:42a0::81]: STARTTLS 454 TLS currently unavailable
the MX host always declines STARTTLS. Is this deliberate? Or something that should/could be fixed?
participants (3)
-
Mark Elkins -
Michael Grimm -
Viktor Dukhovni