I don't have a source, I'd have to dig through my browser history, but I
looked at some of these stats just last month.
Roughly 2% of the top 1000 domains in the United States had deployed
DNSSEC - which I *think* is double what it was a year ago.
Roughly 7% of ISP recursive DNS servers enforce DNSSEC.
Comcast does and Google's public DNS does. Those are the big ones that
enforce DNSSEC on their recursive servers.
I do not see any statistics for DANE adoption, either on port 443 or
port 25 (the two where it is most common currently)
Roughly 20% of all e-mail traffic in the United States was not encrypted.
Of the e-mail traffic that was not even encrypted, a large percentage of
it was spam. What wasn't spam was often sent by scripting languages
(e.g. php) running blogs or other web services.
Only a small percentage of e-mail sent by clients through a SMTP server
was not encrypted in the MTA to MTA transfer.
-=-=-
What we can do as sysadmins, we can run unbound on our local machines,
it defaults to DNSSEC enforcing. That way we don't have to worry if the
recursive resolver our ISP uses is part of the 7%.
Linode enforced last time I checked, but I don't know about other
hosting services.
Still safer to just run unbound listening only on the localhost, and
configure /etc/resolv.conf to point to ::1 (or 127.0.0.1)
If at all possible, deploy DNSSEC on any zones you have control over.
Even without DANE, DNSSEC greatly improves security for the 7% (and
growing) recursive resolvers that enforce DNSSEC.
Before deploying DNSSEC do a lot of reading on it, because if you screw
it up, those 7% enforcing recursive resolvers won't resolve your zone.
I personally use a 2048-bit KSK and a 1024-bit ZSK.
The KSK is what you have to get the DS record for uploaded to your TLS,
and it should be rotated once a year.
The ZSK is just in your zone, best practice says to rotate once a month
but I rotate once a week, every Sunday. It should be automated, so it
doesn't hurt to do it more often than the once a month. Doing it once a
week means if my zone signing server is down or under DDoS when the
signing happens, it isn't a big deal, because it happens 4X the best
practices recommended anyway.
With our web applications that send e-mail, don't use the SMTP services
of the scripting language. Yes it is cool that you can play SMTP server
with PHP etc. and yes, if PHP is built against a TLS library it can
encrypt, but don't use PHP to play SMTP.
Run postfix on the web server and have your web applications connect to
the SMTP on the local host.
This isn't just for the benefit of encrypting, it also lets you do
things like sign the message with DKIM and if your postfix is new
enough, check the DANE records of the MX record the message is being
sent to.
I don't know why so many web applications try to play SMTP themselves,
it is a very bad habit and usually results in mail being sent without
TLS and sometimes rejected by spam filters if the domain it allegedly
comes from uses DKIM but the web application doesn't.
-=-=-
Hope I didn't bore too many people, or offend anyone, these are just my
opinions and this is a topic I am passionate about.
I think system administrators need to do a better job at securing
Internet infrastructure.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
